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