DataWebTect

An interesting post on the mundane issue of switching context of the programmers. I am sure everybody has been there in that situation. Here the author describes the situation wherein a programmer was dragged into fixing a bug for an old project while on an iteration of the new project. I can see eye to eye on how we feel if we are dragged in between the productive work to dig and identify the problem. More often than not this takes many days to resolve, meanwhile we cannot concentrate on the new project nor on the old one resulting in lost productivity.

Dmitri Zimine has taken the stand that the programmer should not be interrupted with here iteration and the project manager need to be convinced that he wait until the iteration was over. But Joel has taken the opposite stand eventhough acknowledging Dmitri’s stance.

The issue is paradoxical because on the one hand if you interrupt and change the context it would take more time but if you don’t fix the old bug it would take away a customer. Here I have to lean towards Joel as “customer is God”. How often have we seen the exodus of clients because of poor customer service and the same applies if the bug in the old software is not fixed the customer could go away and there would not be any takers for the new product. Joel gives a nice example of how they fixed the bug in copilot because of the IE 7 and convinces that Agile is about switching contexts fast and producing results. Again we do not know the real life situation which could have triggered the kind of response Dmitri has taken.

Stevey of google talks about the Good and Bad agile in his “Good Agile, Bad Agile” post. He has clearly depicted his perception of Agile programming. He talks about the incentives to the engineers based on their performance in a particular project and that they do not have any deadlines in meeting the projects except the quarter end when they want to be on the big screen to get their fat bonuses and other perks. No wonder google is growing in leaps and bounds because of the way they treat their engineers. Not every company does that and it is not uncommon for the engineers to be treated as just resources to meet the end. Very interesting post and it could take an hour to read and digest it.