Monday, 6 July 2015

Clean Code (part two)

I think all of us would be familiar with Lego blocks, or for that matter some kind of building blocks as a toy. We would agree that it is very intuitive to use these blocks to build a model of something, say a tower or a vehicle. Small children can also use it easily without prior training or detailed instructions.

Let us do a simple experiment. Take a picture from a newspaper or a magazine and cut it into 10 pieces. Ask some one to assemble it back. Now ask the same person to assemble 10 building blocks together into a tower. Which would be easier?

Why is it easier to assemble the building blocks?
I think it is because, structurally and schematically, they are more intuitively understandable.

Incremental development is like this. It is about assembling your product by joining the incremental software pieces. If each increment were as intuitively understandable as a building block, building our product by piecing them together would be easier. Clean coding can help us to create software increments that are intuitively understandable.

In the last blog, we discussed about the three clean coding skills - Guidelines, Refactor and Reuse. We will discuss another three skills which are as much useful for clean coding as the first three.

Skill # 4 Developer Testing

This skill would require us to do developer testing in a new way. We need to learn four new methods for this:

  1. Test early and often
  2. Explore
  3. Arsenal and
  4. (Play!) football
Please check out my earlier blogs about Developer Testing; about the current traps ( and the better alternatives ( for a discussion about it.

Skill # 5 Great Tools

In the website "The Tools Artists Use" (, we can find references to the works of several artists and their tools.

Tiffany Bozic, the artist uses the following artistic tools:  acrylic paint, Adobe Photoshop, Golden High Flow acrylic paint, Liquitex paint, maple wood panel, mechanical pencil, Moleskine watercolor notebook, Sakura Koi watercolor sketch box, watercolor paint

The artist Rebecca Monk uses Adobe InDesign, Adobe Photoshop, acrylic paint, brush pen, crayon, G-pen nib, Google SketchUp, graph notebook, ink, marker, nib pen, pencil, sketchbook, Wacom tablet, watercolor paint

You can observe here that each artist builds their arsenal of tools and it characterizes their artwork. They give credit to their tools as much as their artistry to create such uniquely wonderful sketches. They also reiterate the aphorism, "the tool is what you make of it".

There is a wealth of information in the internet about the various static code analyzer tools which can be used for different programming languages. The website below compares three popular static analyzers used in Java.

The sensible programmer may not really care about which one is the best tool and would rather use a set of good tools to her advantage.

While it is very easy to gloss over a code level error in manual review, many modern analyzer tools do a decent job in finding them. I have the following two recommendations when using these tools.

  1. It is more probable for a manual review to overlook a known pattern of code level error than a tool. Believe it and use tools sensibly for efficient debugging.
  2. Treat each high severity issue raised by the tool as a potential clue for a major defect. Analyse them thoroughly and defend in depth if need be. It may be tempting to fall for the “tool is broken” mindset, you may be wiser to avoid it. If there are many such issues, which happens often when you run such tool on an existing code base, treat them as high-risk-debt and pay off progressively.
In the course about Software Security (, Michael Hicks explains how static analyzers work in his “Week 5” content. Static analyzers use a logic similar to neural networks to analyze code. They analyze the code some what like our brains do. 

Thus clean code and such tools are the part of a win-win loop. Clean code can help the analyzer tools to work better, just like clean code is more palatable to our brains. Analyzer tools in turn can help the code to be cleaner.

If an analyzer tool is giving many false warnings, chances are that it is finding it tough to “read” our code. A good check at this point is to see if we can read the code ourselves, without getting lost. Refactoring our code for better reading can help the analyzer tools to work better with it and may consequently reduce the number of false warnings.

Skill # 6 Pairing

When I let go of what I am, I become what I might be                                                                                       -- Lao Zi

To a programmer, the code is her signature. It is an extension of her ego. This may be a reason why code reviews involving hand-offs don’t work too well. Many programmers may consider the review to be an attack on their egos.

Pairing, on the other hand, is like teaching to fish. It is relatively ego less collaboration. The more experienced of the pair touches base with the other person at regular intervals and then sits back, allowing her pair to learn deeply. It is like the guiding hand on the back of a cycle while learning to ride, all the while realizing that one has to let go for the rider to learn.

When I pair with a learner, I do it once or twice a day, usually once in the morning after our daily scrum and once in the evening to retrospect the day’s learning. Each time I spend some twenty to thirty minutes with them. I would change the code, demonstrate some refactoring, share a new tool, add a few tests that may fail because of an error and guide them to more insightful learning opportunities.

Pairing is a time-proven solution to learn any new skill. The gurus and zen masters of the orient have used it to great effects for over centuries. It is a great skill to practice and experience a return to our teaching roots.

No comments:

Post a Comment