Wednesday, 22 July 2015

Eat that elephant! (Agile Planning)

How to eat an elephant? One bite at a time
                                                                      -- Pop Quiz

What is the biggest predator in the Arctic?
It is the polar bear, right at the top of the food chain.

image credit Connie Barclay, US Fish and Wildlife Service; license : public domain
Recently, I read about Dr. Ian Stirling who has put more than forty years of research (hats off!) for this marine mammal. Yes! You read it right. The polar bear is classified as a marine mammal (Ursus Maritimus) because it spends much time in the icy cold waters of the Arctic; hunting for its favorite prey - the Ringed Seals.

Most people, especially children love these furry white giants. Did you know that they have some amazing adaptations to live in the extreme conditions of the Arctic?

Take their oily and furry coat. It serves to waterproof during swimming and protection to the biting cold. They can shut their nostrils while swimming so that the water does not enter it. The thick layer of fat under their fur coat adds further protection to the arctic cold. It may be interesting to know that they are more troubled by overheating, when they run than by the freezing cold.

You can read more about them and their interesting ways of life at Polar Bears International

Planning, working on and tracking an agile project are very much like these adaptations. You would plan and work on small batches and get reassurances through the multiple feedback loops. All of us have a natural ability for this since childhood; say from the time when we first learned to walk. As babies, we would take a few steps (agile is rich with such "baby steps" metaphors), perhaps stumble, sit for some time and try again. We got our feedback from the cheers, the supporting hands and the plush living room sofa.

Agile project planning and tracking are like these adaptations in life; prefer small batches and use multiple levels of feedback. And the best part is that it comes naturally to all of us.

I cringe when I hear someone talking about the agile process "compliance". It is up to each team to suitably adapt the implementation of small batches and the multiple feedback loops in their project situations. Common sense and our instincts are a good guide while adapting.

Let me share the case of a team which had started its transition to agile using Scrum. In the beginning, the product owner had the understanding that requirements were called User Stories in Scrum and tried to fit them in the Post Its (using some rather tiny fonts :). After some training about User Stories and Product Ownership, the team came up with a checklist for User Stories which had items like 
1. Does the story have less than three user acceptance tests? (It is suggested to split if there are more than three user acceptance tests)
2. Is the story estimated for size and the estimate less than 13 story points? (The team used the planning poker)
Even after this, many stories took more than a week to complete and many could not be completed as planned in the sprint. For some completed stories, the user acceptance tests found many issues related to its user experience and implicit behavior.

A retrospective suggested that the product owner would stop himself after writing the second or third acceptance test case for every story. Sometimes, he would just explain these "missed" test cases as some scenarios in the requirement brainstorming.

A checklist of good practices which worked well for some teams may not work as-is for us, in our team and context. What may be more effective would be an understanding (and appreciation) of the aphorisms behind these practices; in this case it is about preferring small batches and using multiple feedback loops.

We can size a user story to check if it fits the small batch size condition visually; by checking whether a story description is within one or two lines or intuitively; sensing that it is bigger if we find ourselves discussing about for more than say 10 minutes in a brainstorm or instinctively; recalling that last time we did something like this took us much longer than two days or reflectively; we did coding for a day and in the daily scrum of the day after, we feel that it is going to take longer than one more day. Agile planning, adjustments and tracking are about such adaptations.

Coming back to our furry friend, the polar bear is a picky eater, like a food connoisseur, in the winter when the seals are easily available. They would eat only the fat of the seal and leave the rest for smaller predators like the arctic fox. However, in late summer as the ice recedes, the seals migrate further north to areas with deeper ice. The polar bear would have to survive the summer by feeding mostly on dead whales that wash ashore. They have even developed a keen sense of smell for finding such food. 

Adaptations are quite wonderful; they fuel the life on.

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.