Zero-Defect Anyone?

Code Transition, Maintaining Legacy Code – not words that software managers and coders are enthused by. Yet, that is what we all do, most of our working lives. Maintaining your own code is “bad” enough. When it is someone else’s, it is worse. And taking responsibility for code that is transitioned to you from a far-away geo-site is the worst. But that is what we had to do. It was an opportunity handed to us on a plate. And they say one should never look a gift horse in the mouth. So we didn’t. We went into the situation fully knowing what to expect – rotten teeth. The module of code that we were being handed was riddled with bugs. It was rumoured there were more (potential) bugs in it than lines of code. On top of it, it had been released to customers, so there were customer issues. The module implemented a new standard of part of the language, but that standard was evolving. As we and our competitors added the support for it we found inconsistencies between the functional specs and the reality on the ground. And this part of the standard allowed customers to talk to the core engine of our compiler system at runtime – it was an API – so it had to be perfect. Some of our customers were building their own products, utilities and tools using this API, and demanded not just correct behaviour, but also blazingly fast performance. So there it was, an impossible situation – just what we wanted. It needed the best of hands, and I had one such person. Amit was a person with a large heart, a large smile, a large body, and guts of steel. He was a thorough coder, a methodical tester, an imaginative designer, and could negotiate an arms reduction treaty with the North Koreans. The only thing that ever shook him was the 5.6 Richter scale earthquake in the office, or (I am ashamed to say), the regular one-on-ones with me. Frankly, the only reason he was not nominated for a role in Superman was … well, I don’t rightly know. So it was this paragon of virtue that was sent off to start the transition. Within a week he had charmed the “enemy”, the team that was handing us over the code. And by the time he was back home, he knew more about the current design, the tests suites, the upcoming release plans, the bug-list and the relative priorities, and the machinations inside the standards body, than any other person alive. Also, he could build and test the module, run diagnostics, and debug issues like the best of them. He even fixed a few critical outstanding issues as part of his ramp-up. Next – the team. The previous team had six people, so that is what we needed too. Except that management could not create that many “reqs” (short for requisitions), and anyway “wasn’t the standard almost fully implemented?”, they asked. I could do with five, they allowed magnanimously. We could not cannibalise the rest of the team, at least not too much. And how would we frame the cross-hiring into this new team? Shackleton’s famous (purported) ad for the South Pole expedition comes to mind – he would have been perfect, to draft one for this team – “Programmers wanted, to work on bug-laden code.You are expected to work 90%+ of your time fixing bugs, re-architecting legacy code, and face angry customer emails all the while. And all this, yesterday”. “Avoid this like the plague”, more like it. “Career-destroying move ahead”, another likely blurb. Well, some people ARE foolhardy, so we drafted two of them. Then cast our net far and wide, and hired two more. Set them under Amit’s tutelage to master the standard, the spec, and the current design. He went at it with a vengeance – a Marine boot-camp sergeant would have been ashamed at his own tardiness. By the end of this two month hiatus – the “grace period” we had before pressure started mounting on us – the team was one living, pulsating organism, bonded to each other, fire in their bellies, and all that jazz. Time for a bombshell – why make it too simple for the lads? “Zero-defect”, I announced, in one meeting with this team. “That is your goal”. Zero critical bugs in their code (critical bugs were production-stopping issues, with no work-arounds). From the QA team or customers. And not just on new code they write. This was for the module as a whole. “You own it, you own its history”. Howls of protest. “Hall of fame work, my friends”, I said. I promised to keep the new features down, for one release. Within that time, they had to clean the whole thing, and add new code that was squeaky clean. If they did that, the time spent on fixing legacy issues would drop from 90% to less than 10. Most team spend more than 50% of their time on fixing past issues – previous release issues, current post-alpha issues, beta issues, QA-filed bugs, and so on. This module had been on an even 90% for two releases, and we had been falling behind more and more on new feature addition, performance, and magic, things that make a product (or parts of it) shine. “Get this ratio down to 9:1, or better, and create history. All the time in the world to do what you want to do – write new code, improve performance, enhance capacity, add magic”, I continued. “You will be our ZD Boys”. Spandex will be free of charge. The costume would be blue and red. Despite this rousing performance and the hyperbole, the heart-stirring promises of health, wealth, happiness, unending booze, white sands and sex (okay, not that), and full-nights of sleep, it took us a week before everyone bought into this vision. And that was because we promised we would do this systematically, make schedules based on the engineers’ estimates, and get help from other people to do code, test-plan and design reviews. (To be continued)