agile

Automation in testing – part 3

I would like to share with you an example that totally changed my perception of how I look at automated checking, whether it is unit or integration.

I am programming a lot in .NET. The language I use is C#. The code written in the end is packaged in a .dll or .exe file. If you will look at the content of this file you will not see C# code. You will see MSIL code which is like an assembly language. This MSIL at runtime is translated into processor code.

Here is a C# code, it is taken from the book CLR via C#:

This code is a little bit weird. I admit that it is an extreme example. But it helps me communicate what I want. Let’s suppose that we covered, so to speak, this code with unit checks done ok. Lets also suppose that the code review was quite rigorous and carefully done.

I have some questions:

Is it just a line of code?
How many memory allocation problems can occur?

Let’s change the perspective. What you see bellow is the MSIL code generated from the C# code you see above:

Side Note: By the way, this MSIL code generated from a .Net Core code. Do you think it’s very different from .NET 4.8 code? The answer is no. I ask this because there are people whose CVs will not be accepted because they have not worked with .NET Core, but have experience with .NET. For me is an indication that we focus too much on shallow things.

All those things you see marked with red indicate a place where memory allocation problems might occur.

From my experience not a lot of .NET programmer’s look at the MSIL code. But let’s think about unit checks. You see, what you do know isn’t canceled, it’s okay. But now don’t you think about code coverage in a different way? It’s something else, isn’t it?

Note: For Java we have Java bytecode

This perspective helped me, in this context, to understand that I can think, for example, of memory corruption coverage. Which is just another type of coverage. But I wrote this post to try to answer another question which is: What bugs you aren’t finding while you automate checks? For me, as a programmer, it is very clear that I focus on a certain direction when developing an automated check and nothing else. But focusing on a certain direction means ignoring other dimensions. In the example above I would have ignored memory problems or what MSIL code is being generated and the kind of instructions which will actually be run.

This is a three-part series:

Automation in testing – Part 1 – Do you think it is normal to say test automation? Really everything can be automated in testing? Are we focusing automation goodness in a good direction?

Automation in testing – Part 2 – Do we really need to concentrate our automation efforts in simulating users via Selenium or other tools? Isn’t this a sign of other problems that cannot or will not be solved?

Automation in testing – Part 3 – What bugs you aren’t finding while you automate checks?

Thank you Johanna Rothman

Automation in testing – part 2

Do we really need to concentrate our automation efforts in simulating users via Selenium or other tools? Isn’t this a sign of other problems that cannot or will not be solved?

I really understood how I should look at the role of automation in testing when I participated in an audit. The role of that audit was to help a company to obtain information, also technical information, in order to know if the acquisition of that company would be made. My responsibility was on the technical part to look at the code and the technologies being used. When investigating the code I noticed some patterns. There was no tool on the market to help me, somehow expose what I observed in that context. So I wrote it. In this way I was able to show and articulate the more complicated parts from the less complicated ones in that code which were specific for that project.

That’s the moment when I realized why we should use the “tools” word instead of the “automation” word. Also is then when I realized how limited we are when using the idea of automation/tool. We can use/create a tool to, among other things:

create test data, for example by using combinatorics, Montecarlo simulations, de bruijn sequences;
to analyze and display the logs in a certain way;
to see where to focus our attention at a certain time, depending on what is in the source control;
exercise the system in a specific way so that the tester can observe tangential and oblique problems.

In other words, we do not use this tool idea to its value and power. We limit ourselves through the UI to press some buttons. We use this automation thing, as I observed, only to try to simulate a user. How strange, we use a machine to simulate a thing only a human can really do, but do not use the tool/automation for things which are supposed to be used.

So, back to the questions from the beginning of this post: Do we really need to concentrate our automation efforts in simulating users via Selenium or other tools? Isn’t this a sign of other problems that cannot or will not be solved?

As a programmer, so from a technical perspective, I have observed this obsession to simulate users in an automated way when:

the product code is very bad, so is hard to include any automation checks or testability points at a fine granular level and because of that nothing will be done about it;
when there is no trust in the automated checks done at a fine granular level;
when programmers do not know how or do not want to do automation cheks;

As a manager, I have observed this obsession to simulate users in an automated way when:

Testers see that what is payed in the industry is this user simulation automation, so they find any excuse to do it;
When testers do not know what testing is and how to make a test strategy. Because choosing a tool as selenium and implement automation checks is not a test strategy – but this is for another post;
When managers have no clue what testing is. But they are delighted when they see some encoded test cases in a wiki page and even happier when those (preferably all) are automated whatever that would mean. I wonder how their reaction would be if we would insist that their whole work be automated, probably not too well.

So, I have a new heuristic to spot problems in testing regarding automation which I named it “Automated user simulation heuristic”.

I think that using automations/tools in testing is really cool and useful and there is no doubt about it, not for me at least. Too bad that we focus on the wrong direction in using it.

This is a three-part series:

Automation in testing – Part 1 – Do you think it is normal to say test automation? Really everything can be automated in testing? Are we focusing automation goodness in a good direction?

Automation in testing – Part 3 – What bugs you aren’t finding while you automate checks?

Automation in testing – part 1

Do you think it is normal to say test automation? Really everything can be automated in testing? Are we focusing automation goodness in a good direction?

For me, also as a programmer, testing is, among other things, about finding those relevant patterns that matter within a complex system. But in order to understand complex systems a person must interact with it. But how do we do that?

If you look carefully in the image of the post, you will see a forest. Forest represents testing. Trees represent parts which form the forest. But let’s not confuse the forest with a tree. Each tree has its role in that environment.

Small note about words: Some time ago I worked at a company in a management position. Weekly we had a meeting between all the middle managers. What I noticed in these meetings, which were held in my mother language, Romanian, is that we used a lot of English words. I am speaking about words which have a good translation in Romanian. In one of those meetings I realized how superficial I was. Why can’t I speak about those concepts in my language? So I began to be more careful about this aspect. When I tried to translate and adapt those words in my mother language, I began to understand even more the topics I wanted to speak about. It is then when I really understood the power of words. How they can be used to stimulate thoughts, awareness and insights.

As a programmer I wrote and I write a lot of code, and also code to verify the code written. And now when reading the previous sentence, I realize that I do not write code to verify the verification code. Interesting insight I had by just changing the formulation of an idea.

But I noticed something also. The verification code I was writing was on things which were clear, deterministic which could be approached in an algorithmic way. How does this relate to testing? For me this is a technique to find problems in code.

But I can also use other things when testing like modeling, questioning, inferring.(see the blog post image).

So those automated verifications are part of testing like the others. Personally, I like to call these automated verifications also automated checks.

Therefore this checking stuff is included in the testing, it is an integral and fundamental part of the testing. But we can’t say that only this aspect defines testing. We can say that it is a component of testing. And this part can be automated because it is an algorithmic verification.

If I got involved to understand what testing is , it is because I had the occasion to work with wonderful testers. And I wanted to understand their craft. These testers actually did not have coding skills, but still they were able to find interesting and important bugs. I saw how they used their social knowledge to make a lot of judgments about what to test, how to test, when to stop. There is no algorithm to make these reflections, judgments, assessments. What actually I noticed was how important is the human aspect in testing. Like a conductor who conducts an orchestra and the musicians who use the instruments(tools) to generate the music. Those instruments can be mechanical, but also digital, whatever is needed to transpose the music.

I asked at the beginning of this post the following question: Do you think it is normal to say test automation? I did this as an invitation to see what we might miss if we frame it this way. For me, each time when I witness this framing I see an overemphasis on one dimension of testing and all the others dimensions ignored. That’s why I like to say automation in testing because it serves as a way to increase awareness on how automation relates to testing and that other things might be considered also.

This is a three-part series:

Automation in testing – Part 1 – Do you think it is normal to say test automation? Really everything can be automated in testing? Are we focusing automation goodness in a good direction?

Automation in testing – Part 3 – What bugs you aren’t finding while you automate checks?

What is testing for me

Some days ago I had the occasion to make a presentation regarding testing. But I had one dilemma before. How could I have been able to do this presentation without me being able to say what testing is for me?

There is a concept, praxis, that started my quest to understand how theory can inform and make sense in the practices, in my day to day work. And when I say practices I think about practices in testing, management and programming. There are lots of them. I began to cover some of them, please look here for examples. The concept I am speaking about now is the complexity theory.

Is not easy to explain this complexity thing. I like how Edgar Morin explains the complexity. For him complexity is like a tissue or fabric of inseparable associated diverse elements. But at a second look, those elements represent: events, actions, interactions, feedbacks, hazards.

I like the header image because it is trying visually to show this complexity. You can see in the image some dots, connection between the dots, but it also shows patterns that can be formed (different lines, triangles, pentagons, polygons and so many others). In our day to day life those dots might represent things like:

Technical details in our product(components and objects relating to each other, the fractality of the code, mixing up unrelated abstraction and so on)
Humans with their roles working on a product
Risks
Requirements

And then there is another important detail and that is the fact that humans think in patterns.

So, what is testing for me? Testing is about finding those relevant patterns that matters within a complex system.

Those patterns might mean whatever is relevant in spotting problems within the product or process. These patterns are not static, they continuously change.

Risks, feelings, management

What if everyone –our managers, auditors, testers — got it wrong with the topic of risks?

What if what we witness regarding risk management is just a charade ?

Long ago, I read Jerry Weinberg say, “The definition of quality is always political and emotional.” That resonated with me then and still does.

I had to get out of a project. At that time I occupied a management position. Usually in taking over a project there are some intermediate steps that need to be done. There was no pressure. It was time for my replacement, let’s call him John, to take it over.

John was also in a management position. We both worked on the same big suite of products. My project was an integration project, making the communication between products from the suite work. Part of the problem in my project, before taking over, was that it contained hacks. By hacks I mean things which did not belong there at all but on the other products,at the source.Unfortunately, managers from the other products did not want to apply the needed fixes on their parts, to remove those hacks. So all the garbage needed to be fixed on their part was thrown on this integration project, before I came.

My team fixed these problems in both the integration product and the other products from the suite.

As I reflect back on my conversations with John,I remember several things that appeared “off.” He seemed very detached about topics we needed to discuss in order for him to take up the project . My perception was that John had exaggerated detachment. When he spoke with me everything was ok. But with the others(management from client , our management, teams) his conversation was all about risks.

I did not mind at all that John was concerned about risks. What I did not understand in those moments was his lack of convergence. John spoke with me about risks but in a calm way. When he spoke with others he was doing it in an alarming and exaggerating way. Also I have noticed certain resistance from the teams he had. Anyway that exaggerated perceived detachment in combination with how he handled the risks puzzled me.

Feelings, as much as data, play an important role in decision making.

Then, I found some scientific research about risks, the risks as feelings hypothesis. This hypothesis says that response to risky situations and how we evaluate them are influenced directly by our emotions/affect. The traditional models of evaluating risks tell us about probabilities and consequences but nothing else. But these, actually, are seriously influenced by feelings.(1)

But there is more. You may wonder why us , in IT, should we care about these studies? Because, is about validated scientific knowledge. Things which other disciplines already studied and proved it. We only have to cross the corridor to these disciplines and learn from them. I like the word praxis to describe this.

So, I spoke about the psychological part. But there are also sociological and anthropological studies. These studies show that risk perception has roots also in sociological and cultural elements. For example, the sociological component is telling us how we are influenced in dealing with risks by colleagues, friends, family. The anthropological component tells us that people within groups minimize certain risks and exaggerate others as a way to maintain or control a group.(2)

I realized John had feelings, and those feelings might lead him to assess risks differently than I did. Maybe he felt fear because of the history of the project.

As said above there is also a sociological part which might help in making sense of this situation. I tried to understand from whom he was taking certain technical information. Who was advising him on this part. And I realized it was about some of his team members who did not want to be involved in the take over.

The anthropological component helped me to understand the exaggerated escalation to management. It was a way to maneuver the management groups by playing with risks.

Till that moment I only witnessed a shallow view of how risks were used by management. It was an eye opener to me regarding risks and how they should be used in management, testing, audits.

I mentioned audits. I would like to see an auditor knowing these aspects of risks. Maybe this will help in order to be able to see the spirit of the law and not just the letter of the law. Risks combined with the tacit knowledge might help understand the why’s of why certain risks are articulated, handled and made public in a very specific way. Audits is not about simple receipts ignoring the context and professionalism of a discipline.

Emotions play an important aspect in, risks, judgment/evaluation/assessment. How right Jerry Weinberg was.

(1) Risks as Feelings, Loewenstein, George F. and Weber, Elke U. and Hsee, Christopher K., Psychological Bulletin, Vol. 127, 2001, Available at SSRN: https://ssrn.com/abstract=929947

(2) Perception of Risk, Paul Slovic, Science 17 Apr 1987:Vol. 236, Issue 4799, pp. 280-285, https://science.sciencemag.org/content/236/4799/280

Tacit knowledge, testing, requirements, management

Have you ever wondered why it does not make sense to ask or expect for complete written requirements?

Do you know why trying to write all test cases to capture the testing needed to be done will bring you to a dead end?

Sometime ago I worked on a big project. There were about 50 people involved. These people were divided into various teams. And these teams handled various products from the entire suite.

One of those products was hard to install. Imagine that simple settings that could be saved in a config file, like xml or json, were saved in windows registries. The installation of the suite in production was a ‘special’ event on its own. I use the word ‘special’ not in a good sense. Each time an install was being done; people were awake in the middle of the night to stay to test it. But this was one problem in a sea of problems.

One day, the man responsible for the product installation announced his resignation. His resignation worried me. I asked my colleagues in the office. They weren’t worried. They said, “it’s a different situation, but look, the man who is leaving also writes in a wiki. So, it will be ok”. They had the impression that all what is needed will be made explicit.

For me this did not make any sense. Not all knowledge can be made explicit. We have a lot of implicit knowledge. Harry Collins in his wonderful book named Tacit and Explicit Knowledge explains why. Imagine that knowledge can be represented like an iceberg. What is above the water is the explicit part and beneath the water the tacit part. So:

weak or relational tacit knowledge – Is tacit because of the relationships between people that arise in a social life context. For example:

* concealed knowledge – knowledge which is kept secret intentionally;

* ostensive knowledge – knowledge which is hard to be described/comprehended. Because of that we point to a word, object or a practice to describe it;

* logistically demanding knowledge -imagine a person who knows where everything is, but would not be able to list it if asked),

* mismatched silences – knowledge kept secret without intention;

* unrecognized knowledge – a person is doing certain things in certain ways. This person would not tell another person because it might not know if these are worth to be told for the second person.

medium or somatic tacit knowledge – is tacit because it is incorporated in the human body. How we type, how we juggle, how we balance on a bicycle. What is also important here is about the contrast between conscious and unconscious processing, just think of the process of learning/riding a bike.

strong or collective tacit knowledge – is about the social aspects/interactions/relations people have and the knowledge that derives from this. These will influence also the social judgment of why certain things were done. The most important thing is that these things cannot be described and learned by explanation; it must be practiced in a social environment.

For me this was the decipher key of this type of situation. It was more than clear to me that even with all the goodwill, that man could not have written everything in a wiki and that things would have escaped to him. And this is ok, normal. I felt calm. I don’t know how to describe this calm; maybe it was a calm because it helped me focus on what I knew would come.

Do you wonder how the story ended? That moment I anticipated arrived, and it was a difficult moment for my colleagues in that project. So difficult that replacement also suffered enormous stress and left.

Connection with test cases:

In the example above I said about that man who had to write about the steps (and nifty details) related to an installation. But this also applies to requirements, test cases. We have the impression that if we will concentrate all our efforts on writing and managing by test cases is the way to go. Actually, it is a waste, a not so good direction because on testing we do much much more. There are so many aspects which can be covered that it is really hard to articulate it.

With this overemphasis on test cases we ignore the way we are and how we gain knowledge. Testing encompases many things like learning, critical thinking, experiencing and many others. A lot of this is not explicit but tacit.

For example, I said about critical thinking, this is for me a form of ostensive knowledge. I used 2 words to point to an entire discipline not so easy to describe and comprehend.

Learning about the product involves also understanding why certain decisions were made about that product. Being aware that certain knowledge will be kept secret without intention, mismatched silences or not being aware that an information is so important that needs to be shared-unrecognized knowledge.

Experiencing a certain product might not be easy at all. Information might popup only when discussing with persons involved in the process of working/developing with that product(collective tacit knowledge).

Connection with requirements:

Is helpful to have things written down especially for remembering them. In Scrum, for example, we write to remember but we do not write to communicate the Product Backlog Items(PBI’s) – the PO tells them.

Also this helps in setting more realistic expectations about written requirements.

Connection with management:

The story I gave was the moment when I understood the importance of theory and practice (praxis) , in this case regarding some aspects of tacit and explicit knowledge. As a manager it helped me to size up an unexpected situation and also be aware of things that might happen.

Scrum trainings with James Coplien

I made a promise to myself, each time I have a great training with a wonderful teacher, to write about it. But there is a catch. I must wait for at least one year to see how it impacted my life, both the training and the teacher.

Last year I participated in Athens at two Scrum training classes, Scrum Master and Product Owner one. This year, in spring, I had an online class about Scrum Patterns.

Premises and Context

There were some things that preceded the classes which, I believe, are worth mentioning. Context matters, a lot. So:

– I knew about James Coplien’s work. And by work I mean: programming, software architecture, Scrum, patterns, management, organizations;

– Before the first class it appeared feasible that I might be a Scrum Master at a certain company. And I said to myself that if I will have this honor, then I should go and learn from someone I respected;

– I said ‘architecture’. This was a very important detail. I would have liked to speak with him for 30 minutes about DCI(Data Context Interaction). You cannot imagine the torment I had and have about this topic which is so important for IT;

– I like programming. I also like testing, as envisioned by Jerry Weinberg (1);

– What I witnessed with managers, scrum masters, companies, clients, teams is that Scrum was not understood. What amazed me was that it was not understood especially by those who considered themselves as Scrum advocates, who were doing coaching/presentations/setting up Scrum, etc. I wish to say something has changed in all these years but I do not have this impression;

Details about the courses

I will try to write about this experience via 3 dimensions. I do this because there are different type of persons which might search or be interested in different kind of information:

–structure: the flow of the classes in those days;

–key words: as I have done it before, I was curious how I can describe these trainings via some keywords used;

–pearls of wisdom: these are insights from the training, words used by James Coplien. You will see that each of the text is within quotes and preceded and followed by “….”. This is because the text has a context(story, experience, people, time, history, feelings, exercise, place). It took James Coplien a good period of time to decipher these. So there is a risk, for the reader, not to decipher the real meaning/lesson/message. I put them there in the hope that it will convince the reader to go at his trainings and find out more;

Structure

Here is the course outline for the Scrum Master course:What is Scrum?

– Scrum history

– Scrum theory, Concepts, Practices

– Sprint Planning

– Production and Sprints

– Velocity game

– Overcoming impediments

– Management distribution and scaling

– Engineering tools and Practices

Here is the course outline for the Product Owner course:Intro to Scrum

– Your job

– The Vision

– Build an organization

– How the product backlog works

– Running the business with a Product Backlog

– Kaizen mind

At first glance it seems just classic Scrum stuff. But no, imagine that all the details/courses were explained/done in a red pill way(2): ”… I can teach you this course in one of 2 ways. One is that you can go back and we’ll call you a Scrum Master, even though you are a project manager. No change to the organization, do the Daily Scrum and say you do Scrum. That’s called the blue pill Scrum …”

Each time a student had a doubt or posed a question, James stopped and clarified. I would have liked to say that there were only fluffy bunnies but no, only cold showers. I have seen ‘senior’ SM or PO who remained speechless, as if everything they knew no longer applied.

Keywords

There were lots of topics discussed in the courses and I did not know how to describe it in a short and coherent way. But also I hope that these words will trigger a further search in context of Scrum and James Coplien. So:

Japan; Toyota Production System; deep japanese culture; zen buddhism; courage; we can’t predict; (prediction) in software; nature; human kind; harmonizing; value; outcome; self organization; type A,B,C Scrum; respect; consensus; timebox; kaizen; hansei; mura; muda; muri; Scrum scaling; emergent requirements; mercenary developers; enabling specification; trust; continual, not continuous, improvement; chief engineer in Toyota; kaikaku; ISO 9001; proxy product owner; quality Sprint; testing (advising the students to read ‘Lessons Learned in Software Testing’ book ); complex adaptive systems; waste; kanban; productivity

Pearls of wisdom

As I said it is important to mention that these phrases do not have context around them. This is intentional. It is an invitation to dig more, to go to the course. So:

-”… Scrum is not about replacing the Project manager with Scrum Master and the Product Manager with a Product Owner and doing daily Scrum. Is turning the company upside down …”

-”…A lot of Scrum trainers do not understand Scrum…”

-”… Taught right, Scrum is a lot like aikido, it’s a way of life. So is not just about how you do things at work, but how you relate with other people; it’s a world view from how the world works and how we work together…”

-”…Does a complex adaptive system have a root cause?…”

-”…Productivity is the number one cause of waste…”

-”…There is no user story in Scrum…”

– Student: “My team is distributed in 2 continents”

James Coplien: “…Teams are collocated…”

– “…You can’t promise you will deliver anything in a Sprint…”

-”…we never say commit to a schedule or commit to the content of the Sprint backlog but you are committed to your team…”

-”…You don’t have a chance of prediction in a complex phenomenon…”

-”…No Jira in Scrum…”

-”…Scrum is about controlled failure. Is not going to put you in a happy buble.Is going to make problems visible. Scrum is going to cause you so much pain. There is no magic here, just hard work…”

-”…Outsourced Product Owner is total bullshit…”

-”…Don’t you ever have a quality Sprint, every Sprint is a quality Sprint…”

-”…It’s about people. People working together…”

-”…This myth that it takes a lot of people to build a big product is a myth. Why do we scale? Because we can…”

-”…The Scrum Master is the single wrenchable neck for the team’s delivery…”

-”… The goal is not to do Scrum; at Ri you drop Scrum …”

-”…Please tell me you are not doing SAFe…”

-”…The point is that Product Owners do not work in Sprints. They have a continuous process of market research, exploration,…”

How it helped me

Before all these classes I felt things were wrong on how Scrum was introduced, taught, spoke, presented, imposed, described. But now I know…

I was amazed by the deep things learned about Scrum for the first time, so in 6 months I was in Athena to take the Product Owner class. Also this year I had the Scrum Patterns class.

When I decided to take the first class I wanted/desired so much also to speak, for some moments, with him about DCI. Of course when possible. And we spoke(in breaks, at dinners) … about DCI, but also about Jerry Weinberg, life, Retsina wine, recruiting, unit checking, scaling, dedication, Alistair Cockburn, OOP, architecture, honesty, Heidegger,…

Next on my list: DCI class(I hope he will make it, I am waiting for it for years), and again Scrum Patterns class.

(1) Jerry Weinberg, https://leanpub.com/u/jerryweinberg

(2) Blue Pill or Red Pill – The Matrix (2/9) Movie CLIP (1999) HD, https://www.youtube.com/watch?v=zE7PKRjrid4&feature=youtu.be&t=81

About courage

Some days ago Johanna Rothman published a very interesting blog post named What Does Courage Mean to You?.

Note: I like a lot her tireless way of writing.

I decided to reproduce also here the comments I put there, adapted a little bit, and most importantly her insights – I really believe she touched a sensible cord and I hope not only for me.

At the end of her blog post she says “… Easy to say. Not easy at all to do.

That’s the question: What does courage mean to you?”

Indeed, not easy at all. When I read her post, 4 things popped up in my head which deeply moved me in the course of time. I will dare to say them. I say dare because this is a deep thing, at least for me, not a fluffy bunny motivational nonsense:

● Giovanni Falcone (sicilian judge killed by Cosa nostra and deviated parts of Italian state): He was asked in a interview(1) if he said the following ‘You said, it seems you said, that: The coward dies several times per day, the brave(‘coraggioso’) just once(‘una volta sola’). This means you do not have fear? ‘ and Giovanni Falcone says’ Well.. important is not to establish if someone has fear or not. Is to know how to live with its own fear and not being let conditioned by it. The courage is this, otherwise it is no longer courage but unconsciousness/recklessness’.

● Paolo Borsellino (sicilian judge killed by Cosa nostra and deviated parts of Italian state; husband with 3 kids): On the Thursday before his death he received the notification that the bomb had arrived in Palermo for him. Other 3-4 persons in Italy at that moment had a similar big threat at their lives but they left, he stayed. You know what he did? He called urgently his priest for the confession. He wanted to be prepared for the big departure…

● Nicolae Steinhardt (orthodox monk; his ‘Journal of felicity’ book is one of the most precious gifts Romania has; arrested by romanian communists of that time): The authorities tried to convince him to betray his friends. After the first day of the interrogation he returned at home, they wanted to give him time to reconsider. His father (which, in the past, received the Romanian royal order ‘Military Virtue’ and studied with Albert Einstein) asked him why he returned. The father was tough with him(my translation): ‘What else did you come home to, you bastard/you prick(‘nenorocitule’)? You gave them the impression that you were hesitant, that the possibility of betraying your friends could fit. In business, when you say let me think, it means that you have accepted. For nothing in the world do not dare to be the witness to the prosecution’. After some days he had to return at the ‘Securitate’ . Before living the home his father said to him:’And make sure you don’t make fun of me. Don’t be a cowardly Jew and don’t shit in your pants.’ (note, his father was a jew)(2)

● My grandmother: She had 10 years. She was in the orchard with her grandfather, who raised her. We were just occupied by sovietics. A sovietic soldier entered within the orchard. Her grandfather asked him to leave. The soldier wanted to shoot him. My grandmother stood in front of her grandfather. Their luck was that a woman, passing by, speaking Russian calmed down the soldier explaining that her grandfather was the only relative still alive for my grandmother.

So, what does courage mean to me? Well…for me less words. I hope to behave as it should be when needed. Sometimes I have fear that I will not…

I liked a lot Joanna’s reply she said it so nice: “I often see courage in small actions every day… I also realized that we are courageous on a continuum. When we can, we take our fear in our hands and hold it close so it doesn’t blind us. Then, we take that small step to courage. And, when we can’t take our fear? It takes us.”

After her reply I tried to think at the examples we have in IT world which I know:

● James Coplien says that he, personally, will give a ‘certification’ to a Scrum Master only when that Scrum Master would have lost the job by doing his/her job… And now when writing this, I think this act of his is an invitation to transcend the apparent and even transparent level of Scrum, he raised the bar(is above dailys, meetings , velocity..). Maybe I am wrong with this interpretation, but wow.

● But this applies also when defending an idea day by day. And when I say this I think to James Bach and Michael Bolton and the testing, the one envisioned by Weinberg. Sometimes I feel they are alone in all this IT world which distorted/twisted the idea of testing, but they do not stop. And how easy would be for them to fake and, maybe, do lots of money…

Johanna touched a very very sensible subject which is/was/will be relevant, at least I hope.

(1) Falcone:’Importante non è stabilire se uno ha paura, ma imparare a non farsene condizionare, Giovanni Falcone , https://youtu.be/-Ly9XS4iLj8

(2) Și acum despre frică. Valiza lui N. Steinhardt, Gabriel Liiceanu, https://www.contributors.ro/%C8%99i-acum-despre-frica-valiza-lui-n-steinhardt/

The hidden dimensions of code review(s) – part 2

Some dimensions will be treated in this blog post and on part 3 of this blog posts series(see part 1 here) , my friend, Ionut Albescu will help out with the dimensions and sub-dimensions which were left out.

The dimensions

■ Programming(Design, Clean Code, Refactoring, Unit Checking)

There are a lot of materials covering these aspects. Just search for books by James Coplien, Robert C. Martin, Martin Fowler, Michael Feathers and you will get an idea of each of these topics. Usually, in appearance, this is the dimension were code review is concentrated. I said in appearance because these topics cannot be mastered in a month or two, not at all. But is more, although management/customers/end users will expect programmers to excel in this… well is not quite like this…

Programming – Impact

This sub-dimension is to make the programmer aware of how the functionality she/he implemented will impact the final user. How many programmers think that because of their work an end user can be fired?

■ Testing

Here I am thinking about Context Driven Testing(1) school of thought, especially Rapid Software Testing(2). This testing has its roots in cognitive psychology and epistemology(3). Please read the work of James Bach, Michael Bolton, Cem Kaner, Jerry Weinberg.

If you are a developer and want to ignore this dimension than I advise you to think better. You will lose the chance to be an even better professional.

Testing – History

James Bach, some time ago, pointed me out about the book “Your Code as a Crime Scene: Use Forensic Techniques to Arrest Defects, Bottlenecks, and Bad Design in Your Programs”. I was thrilled to see how many things can be deduced just by looking in the source control history. I was able to see the weak points of code and where to concentrate the refactoring. It was there in front of my eyes the Paretto principle, helping me in prioritizing work, but also helping testers in guiding their test strategy.

Testing – Testability of the application

We need to give the application control points so the testers, programmers can exercise more easily certain scenarios. For example replacing more easily components. If we can’t do this, then is a red flag.

Testing – Risks

4 sub-dimensions listed here are from the wonderful paper “Risks Analysis Heuristics (for Digital Products)”(4): project factors, technology factors, specification factors, operational factors. Studying this paper made me realize that coding is not just about if, else, while… instructions.

The tester(s) have a different mindset, which should be viewed as a complementary to the one we already have, as a developer. Developers look at the code with the assumption that is right, but we need testers to look at the code with the assumption that is wrong(they are negative, they focus on failure(3)).

■ Business

All the code should be driven by the business need. Use cases/activities should drive the code and it’s structure. How do you know that a duplication is not just a temporary one which in the end will no longer exist? How do you know that you are applying ok the Single Responsibility Principle? Well guided by the business, the actors.

Business – Analysis

I remember we discussed the heuristic “Mary had a little lamb”(5). This heuristic help identify ambiguity statements which are in written form. The secret is to concentrate on each word one by one and then in combinations. Let’s take the word “Mary”. We concentrate on this word by posing questions: Why Mary? Why not Giovanni? Let’s take the word “had” from the sentence: Why it had? What happened that no longer has it? What about present, future? Will it have another one in the future?.

I love this technique. A lot of programmers want and expect fully written requirements without side effects. But is not possible because:

– it is a lot of tacit knowledge;

– is one thing for people to see the data(let’s not forget that even with the highest concentration we partially see/scan stuff), one is to pay attention to it and a different thing to act upon that data. (6)

Most of the time we go on the supposition that we know what customers/end users want. But is it like that? What if the end user does not know? What if the end user is unaware of certain things, on which we might help, which are possible and they may want it? Why to code a thing and put a lot of effort in abstractions, algorithms when … maybe … that is not the path to follow?

Is time for a lot of programmers to grow up and not ask for things just because it will be easier for them. Or search for excuses not to do work. They will code certain business things. This means they are directly responsible to understand and make sure they understand those business things. Christopher Alexander put it very nicely: “Please forgive me, I’m going to be very direct and blunt for a horrible second. It could be thought that the technical way in which you currently look at programming is almost as if you were willing to be ‘guns for hire.’In other words, you are the technicians. You know how to make the programs work.‘Tell us what to do,Daddy, and we’ll do it.’That is the worm in the apple.”(7)

Business – Impact

Here is about building products and delivering projects that make an impact, not just ship software.

There is a technique for doing this which is called Impact Mapping(8).

Impact mapping is a planning technique which uses in a very inspired way guiding mind maps in helping achieve this by guiding/facilitating the process. It shifts the focus from just doing what the customer orders to focus on collaborating with all involved parties. The goal of the impact maps focuses on the question “Why are we doing this?” and gives a strong guidance on how to do this. This work collaboration between senior technical and business people is a must because the code changes based on this interaction. The abstractions, objects, architecture is strongly influenced by this. The business must be known by senior programmer – is a sine qua non condition for the seniority of the programmer.

Business – Demo

At the end people will see the result of the code, not the code itself. This result is the desired effect. This means that the end user, the Product Owner have to see it and the programmer to get an early feedback. So this aspect can help the developer to be ok/prepared when doing the Demo.

■ UX

Most often the work of the programmers is reflected in the UI. The final user does not see what is underneath. I really like how James Coplien makes the connection between object oriented programming and UX. Is normal because via UX we try to translate as much as we can the mental model of the user and then that mental model must be reflected in code.

■ Human

Very often we forget the social aspect of programming. We do not realize that architecture, for example, has a social aspect. This is very important.

Is not easy to integrate and make work two or more, different, personalities. I wrote before about this. There can be a conflict, a political stuff, sadness, ….All this can affect and will affect the quality of the code review.

In the mind map we put the word “Affinity” to be aware of all the subjectivity that can be present.

We put the word “Experience” because:

– of seeing bad examples. People who were considered seniors but they were affecting in a bad way how the review was done. Also the other team members, the juniors one, were influenced by these “seniors”;

– the experience plays a role in review because of the learning that can be done. Having an experienced developer that can share knowledge hands on;

– people with no programing experience , like some testers, were posing interesting questions. And the explanation towards them had to change a little bit;

About inattentional blindness, I wrote before about this aspect and code reviews.

Partial Conclusion

– Trygve Reenskaug had an interesting idea: the reviewer having the responsibility of the code being reviewed, not the programmer who wrote it. That for sure will change the dynamic of code reviews and it can make code review(s) more valuable/interesting not just a monoton approve step(9);

– After we (Alexandra Vasile, Marius Jantea, Ionuț Albescu and I) created the mind map and thought together at those dimensions and explanations I realized that in my subconsciousness I might have been influenced by the wonderful book named “Handbook of Technical Reviews” written by Jerry Weinberg(10);

– Seeing how code reviews are being done/treated gave me a clue regarding the dynamic of the team and possible sociological/management/organizational problems that might be there. I say this because a characteristic of complex systems is fractality;

– Do you feel to modify the mind map, to add more dimensions and sub-dimensions? Good;

On Part 3 of this blog post my friend Ionuț Albescu will continue in clarifying the other dimensions which were left out and also will give his personal touch on this subject of code reviews.

(1) Context Driven Testing, http://context-driven-testing.com/

(2) Rapid Software Testing Methodology, https://www.satisfice.com/rapid-testing-methodology

(3) James Bach, “Lessons Learned in Software Testing: A Context-Driven Approach”, https://www.amazon.com/Lessons-Learned-Software-Testing-Context-Driven/dp/0471081124#

(4) James Bach, Michael Bolton, “Risks Analysis Heuristics (for Digital Products)”, http://www.developsense.com/resources/RiskHeuristics.pdf

(5) Jerry Weinberg, “Exploring Requirements” https://leanpub.com/b/requirements#bundle-page-exploringrequirementsone

(6) Dave Snowden, “See-Attend-Act”, https://cognitive-edge.com/blog/see-attend-act1/

(7) Christopher Alexander, “The Origins of Pattern Theory: The Future of the Theory, and the Generation of a Living World”, https://pdfs.semanticscholar.org/7157/ee5a77c6fd64f8b8b2282225f113205370e9.pdf

(8) Gojko Adzic, “Impact mapping”, https://leanpub.com/impact-mapping

(9) Trygve Reenskaug, “DCI: Re-thinking the foundations of object orientation and of programming”, https://vimeo.com/8235394

(10) Jerry Weinberg, “Handbook of Technical Reviews”, https://leanpub.com/handbookoftechnicalreviewsfourthedition

The hidden dimensions of code review(s) – part 1

Context

The title image was created last year in December with the help of three friends (Alexandra Vasile, Marius Jantea and Ionuț Albescu) over lunch. Since then, I try to write about this subject. The trigger point was when, again, I saw a collocated team using exclusively a tool for code reviews and no personal discussion. It was clear to me that I was seeing some effects of bad things that happened there before and people were hiding themselves behind tools – is so easy to do this.

When I asked them why they did it in this way, they had a perfect excuse: audit. Smart things can be done so that an audit will not generate stupid behaviors. I saw that in our industry, at least here in my area, this audit is a good excuse for bad behaviors/recipes. I think there is a gross misinterpretation of the audit intention and on what should be done.

So in this case, as in many others, it was about abnormal/bad work environment, lack of understanding subjects/topics involving our day to day work(audits, code review(s), testing,… ).

The good thing is that it forced me to think very seriously on code reviews and what it meant for my friends and I. I have to say that when discussing with my friends, I had in mind the way how James Bach and Michael Bolton analyses certain things(1).

Why is so important

I continuously saw how this subject, in my opinion, was badly treated. But why it irritated me so much? Well, among other things, because:

– this is how I learned a lot of programming stuff;

– it is so obvious the connection with testing and how helpful is to find bugs;

-it helped me see the connection with the idea of complexity(those things which are named boundaries and how the system will adapt/shape/modelate based on those) (2) ;

– the serious analysis which is being(should be) done can help us arrive at profound stuff;

Checklists

There was a time in my professional life when it was enough to say the words “checklist” and “tool”, when a problem popped out, and everything would have been OK in the eyes of certain managers. I think that those managers wanted simplicity, but most often we deal with an essential complexity. Somehow I felt that, for those managers, the situation awareness always could have been reduced to some simple/obvious things in a very fast way. Everything was reduced to recipes.

Context is everything. This means situations can have different dynamic. I am afraid that for those managers all the situations were all simple/obvious( in Cynefin terms)(3). So for them it was assuring that having that checklist would have acted as a guard with, almost, ad litteram actions described in that checklist – and it makes sense for the Obvious domain in Cynefin, but we are not always there, not at all.

What if a checklist in complex domain, or liminal zone between complex and complicated, has a different form/significance? What if it means something else? I think that at this level we speak about compressed knowledge, cognitive activations, heuristics. They can’t be used ad litteram, is a lot of uncertainty. I understood this when I had the Rapid Software Testing course with James Bach. James had a list of different words regarding testing on a slide, it was a huge slide full with words. Someone could have transformed that list in a checklist but…not ok. Each word from there could have been described in a lot of text and lots of actions dependent on context.

This is how I realized that a professional expert might use a checklist in a different way than a junior would use it.

Maybe also with checklists, in these kind of contexts, the secret is … checklists “all the way down”(4) – and this is a whole different story, for sure not a simple one. James Bach said it so nicely: “Heuristics are often presented as a checklist of open-ended questions, suggestions, or guidewords. A heuristic checklist is not the same as a checklist of actions such as you might include as “steps to reproduce” in a bug report. It’s purpose is not to control your actions, but help you consider more possibilities and interesting aspects of the problem.”(5)

So, to come back to checklists as we know them which are used, most often as I saw it, for process compliance, just tick in the box – which for certain people, not professional who play good politics, can use to cover their ass :(.

Pull requests

Instead of hearing the words “code review”, I often hear the words “pull request”. And of course the link of that “pull request” was sent by chat to the collocated colleagues. I would like to say that this is something new for me, but it is not. But what is even stranger, is those collocated people decide to do exclusively the code review via the tool. This reminds me of the team who was doing daily meetings via Skype although they were in the same office…

I know there can be good scenarios to make code review via the tool. But to have it exclusively, no matter what, via the tool for collocated colleagues is rather problematic.

The justification for pull request(s) most often is, again, the audit.

Why dimensions

I noticed that code review has only a narrow perspective in the eyes/actions of many people. Some aspects, intentionally or unintentionally, are not considered, like: the environment, the context of where that code lives, what generated that code, the possible unintended consequences of the code,…

Is not enough to concentrate on those lines of code only. I say this because of 2 reasons:

– if something is not seen/observed does not mean it does not exist.

– I think that code has a complex aspect in it. This means that we have to see the connections also. Because in complexity is all about connections.

The title image from this blog post was created to show the possible dimensions worth considering, at a certain moment, when doing a code review. It is a guideline.

Depending on the moment when code review is being done, certain dimensions(see the image below) can be ignored while others will matter more. For example, in the image below, I want to concentrate on seeing how SOLID(6) principles were applied guided by the business need:

In the part 2 and part 3 of this series we (Ionut Albescu and I) will tackle these dimensions.

(1) James Bach, Michael Bolton, ”A Transpection Session: Inputs and Expected Results”, https://www.developsense.com/blog/2010/05/a-transpection-session-inputs-and-expected-results/

(2) Dave Snowden, “Boundaries”, https://cognitive-edge.com/blog/boundaries/

(3) Dave Snowden, “Cynefin Framework Introduction”, https://cognitive-edge.com/videos/cynefin-framework-introduction/

(4)”Turtles all the way down – is an expression of the problem of infinite regress” , https://en.m.wikipedia.org/wiki/Turtles_all_the_way_down

(5) James Bach, “Heuristic Risk-Based Testing”, http://www.testingeducation.org/course_notes/bach_james/cm_2002_rapidsoftwaretesting/rapidsoftwaretesting_13_heuristic_risk_based_testing.pdf

(6) Robert C. Martin, “The Principles of OOD”, http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod