Here is a new term, software terrorist, who brings negative productivity to the team. I can attest that catching bug in poorly written code waste a lot more time than rewriting the code myself from scratch.
By Allen Holub, May 2005, SD Times
The 20-to-1 productivity rule says that 5 percent of programmers are 20 times more productive than the remaining 95 percent, but what about the 5 percent at the other end of the bell curve? Consider the software terrorist: the guy who stays up all night, unwittingly but systematically destroying the entire team’s last month’s work while “improving” the code. He doesn’t tell anybody what he’s done, and he never tests. He’s created a ticking time bomb that won’t be discovered for six months.
When the bomb goes off, you can’t roll back six months of work by the whole team, and it takes three weeks of your best programmer’s effort to undo the damage. Meanwhile, our terrorist gets a raise because he stays late so often, working so hard. The brilliant guy who cleans up the debris gets a bad performance review because his schedule has slipped, so he quits.
Valuable tools in the hands of experts become dangerous weapons in the hands of terrorists. The terrorist doesn’t understand how to use generics, templates and casts, and so with a single click on the “refactor” button he destroys the program’s carefully crafted typing system. That single-click refactor is a real time saver for the expert. Scripting languages, which in the right hands save time, become a means for creating write-only code that has to be scrapped after you’ve spent two months trying to figure out why it doesn’t work.
Terrorist scripts can be so central to the app, and so hard to understand, that they sometimes remain in the program, doubling the time required for all maintenance efforts. Terrorist documentation is a font of misinformation. Terrorist tests systematically destroy the database every time they’re run.
Terrorist work isn’t just nonproductive, it’s anti-productive. A terrorist reduces your team’s productivity by at least an order of magnitude. It takes a lot longer to find a bug than to create one. None of the terrorist code ends up in the final program because it all has to be rewritten. You pay the terrorists, and you also pay 10 times more to the people who have to track down and fix their bugs.
Given the difficulty that most organizations have in firing (or even identifying) incompetent people, the only way to solve this problem is not to hire terrorists at all; but the terrorists are masters of disguise, particularly in job interviews. They talk a good game, they have lots of experience, and they have great references because they work so hard.
Since the bottom 5 percent is indistinguishable from the rest of the bottom 95 percent, the only way to avoid hiring terrorists is to avoid hiring from the remaining 95 percent altogether.
The compelling reason for this strategy is that the 20-to-1 rule applies only when elite programmers work exclusively with other elite programmers. Single elite programmers who interact with 10 average programmers waste most of their time explaining and helping rather than working. Two elite programmers raise the productivity of a 20-programmer group by 10 percent. It’s like getting two programmers for free. Two elite programmers working only with each other do the work of at least 20 average programmers. It’s like getting 18 programmers for free. If you pay them twice the going salary (and you should if you want to keep them), you’re still saving vast amounts of money.
Unfortunately, it’s possible for a software terrorist to masquerade as an elite programmer, but this disguise is easier to detect. Programmers who insist on working in isolation (especially the ones who come to work at 4:00 p.m. and stay all night), the prima donnas who have fits when they don’t get their way, the programmers who never explain what they’re doing in a way that anyone else can understand and don’t document their code, the ones that reject new technologies or methodologies out of hand rather than showing genuine curiosity—these are the terrorists.
Avoid them no matter how many years of experience they have.
Software terrorism is on the upswing. I used to quote the standard rule that the top 10 percent were 10 times more productive. The hiring practices prevalent since the dot-com explosion—which seem to reject the elite programmers by design—have lowered the general skill level of the profession, however.
As the number of elite programmers gets smaller, their relative productivity gets higher. The only long-term solution to this problem is to change our hiring practices and our attitudes toward training. The cynic in me has a hard time believing that either will happen, but we can always hope for the best.
