The Art of Firefighting - Part 2

Localization of reference is a concept that holds true throughout the software development life cycle. There is a clear pattern of few chunks of code evolving significantly at any given time. These could be most bug infested code segments or segments most impacted by a change request or impact of a feature addition - irrespective of the nature and phase of software development, there would invariably be few high churn code chunks (I like to call them fire pockets).

Exactly what chunks are churning may vary with the development life cycle stage, e.g. towards the beginning of development, framework and API code might see significant changes while other modules might just be static stubs while later frameworks would have stabilized but other modules would see high activity. Still later in the development cycle some bug infested fire pockets might see a lot of code change.

How is this information relevant for firefighting? :-)

Let us examine some typical characteristics of our situation.

- There isn't enough time. Not the routine "not enough time" but a severe time constraint.
- Lack of time often leads to less than usual unit testing and QA testing.
- Code changes are likely to introduce more bugs.
- More the code changes, more likely that new bugs would be introduced and this relationship is not linear.

Add to these the fact that bulk of code changes are happening in a few fire pockets and voila next mantra to fire fighting is right there - "do not mix tasks". Never ever try to fix multiple issues in one go. It would take far less time to fix an issue, test it, check in the fix, and then proceed to tackle the next issue rather than to implement two or more fixes at one go and then proceed with testing them together.

While you are in the moment, it might appear that you have a handle on the issues and you can easily fix more than one issues at one go but this is similar to running hard and fast in a forest. Every new bug introduced would take so much more time to find and fix simply because lot more code has churned and consequently has low confidence value.

I have witnessed way too many delays and heart burns originating from the temptation of clubbing fixes and yet I have to concede that temptation to add just one more fix to the mix is strong. It is a fire that fuels itself.

To carry the jungle analogy further, if you try to build a shelter and cook food at the same time, you are likely to send an open invitation for dinner to some cohabitants and guess who's on the menu?

Moreover, if you pause and think, how much time difference are we talking about in the two approaches: when you fix one, test it, check it in and then pick up next Vs when you fix both, test them both, and check them in together. Even if we assume best case scenario, i.e. no new bugs were introduced, the only effort saved is time for an extra code commit and one round of set of tests that were common to both the fixes. Given that you are in a fire pocket, racing against time, with reduced testing effort, I'd leave it up to you to calculate the probability of such a best case scenario and its RoI.

This article is second in the series, you can find the first one here - The Art of Firefighting - Part 1.

PS: Pointers to relevant Dilbert cartoons are welcome.

Myth about multitasking

True masterpiece from Scott Adams that shows one of the ills plaguing all levels of contemporary software development. Numerous researches have shown that human brain is not effective at multitasking. In fact multitasking slows us down since multitasking makes us deal with irrelevant information as well.

Yet, all of us have been seduced by the lure of multitasking - overestimating our capabilities and trying to do two(pun intended) much at the same time. Responding to emails while attending meetings, preparing plans while sitting through architectural discussions, watching tv while taking a call from home, we have all tried our hands at it in many forms.

Reflecting on my experiences, I do not remember much of meetings/conversations during which I checked emails and my email responses at that time weren't great either. Unless we stop thinking of the "other things" we are bound to miss the finer details of our current task. That would also explain why reading in the bathroom is not multitasking unless you want to concentrate on finer details of using the bathroom ;-)


So, is multitasking overrated? How does one manage high pressure day(and night) job with new information flowing in constantly?

The answer to those question lies in how you adopt multitasking. Effective human multitasking is not very different from computer multitasking. A processor gives "appearance" of handling multiple tasks at once. However, at any given moment only one task is being executed - not a single cycle is spared for another task. Only a higher priority task can preempt the current task. If current task is interrupted (waiting for input/resource etc) then next higher priority task is picked up for execution.

In a very similar fashion, instead of attempting multiple tasks at the same time, we should prioritize and pick up highest priority task first and then give it our complete focus. Periodically, new information reaches us (new tasks, events) which should be used to adjust our priority and we should continue with execution of highest priority task. Undivided attention to a task is the only way of getting a task done with good quality. This is especially true of high priority tasks where there is little room for iterations for refinement and delays are just as bad as poor quality.

In short, only way of multitasking effectively is to deal with multiple tasks at the same time but not in the same moment.

As a manager, it is extremely important to understand this reality. It is all too easy to put a lot of tasks on a team member's plate. This might render them ineffective or affect the quality of their delivery. If a team member reports little progress on multiple tasks or cites one task as reason for lag in another, it is a strong indication that you need to sit with them and help them prioritize and execute. It might take a few iterations/weeks before team gets into the groove of prioritizing and then executing with focus but it is worth the effort, after all this is indeed manager's highest priority task - building a highly productive team.

Another one: