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:
- Test early and often
- Arsenal and
- (Play!) football
Skill # 5 Great Tools
In the website "The Tools Artists Use" (http://thetoolsartistsuse.com/), we can find references to the works of several artists and their tools.
|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.
- 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.
- 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.
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
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.