Copyright © 2010 Corvus International Inc. All Rights Reserved
That's what I thought when I wrote it.
Commandment #11 of "15 Commandments to Curb Bad Programmer Habits":
Harold was a bad programmer. A really bad programmer. But since he was a nice guy nobody wanted to fire him. So he got moved from project to project to project. Whenever anyone wanted headcount, the manager currently in charge of Bad Harold took the opportunity to offload him onto the next unfortunate. One time that unfortunate was me.
The Keen Team
The best team I ever ran, ever worked with really, occurred in the 1980s. Our defining characteristic was that we wanted to be a good team. We worked very hard at being a good team. And as we became a good team, we worked harder at becoming a better team. We supported each other, we developed processes and tools, we implemented high-quality inspections, we developed an innovative testing approach, we did lots of things to become a good team. One of our criteria was that we would accept no bad work from anyone. We would provide whatever resources were needed so that each person would be 100% successful. We even defined the metrics for that success.
Then Harold joined the team.
Harold Writes a Program
We explained the team's rules of the road to Harold when he joined us. We then gave him a simple program to write. The program package contained good requirements, an excellent reviewed design, ideas on how to test and many other resources. Harold, however, decided to simply write what he wanted to write, the way he wanted to write it. Needless to say, his code failed the inspection. Harold was furious. He had never been called to account for his work before. In fact he had even unit tested the program an asserted it worked and we were forcing him to rewrite something that already worked.
We didn't budge. We required him to rewrite the program. To his eternal credit, when he did rewrite the program he acknowledged that our design was much better than his. In fact Harold became a believer and a vocal advocate for our (now his) team and processes
Bad to Good
An interesting observation: while we were a good team before Harold arrived, we became a better team with Harold on board. In fact, we were a better team because Harold was a bad programmer. It caused to better define and adhere to our processes and rules, it evoked a higher ethic in the whole team (including and surprisingly in Harold), and it allowed Harold to have pride in his work for perhaps the first time in his professional career.
Perhaps more than anything else, however, it illustrated a key point: we as a team chose not to do what other teams had done which is simply to discard Harold as worthless--we provided just what was needed to help him become a valuable member of the team. This made us a better team than we would have been without Harold.
Our team's inspection process had "levels" of acceptance for work products dictating how much rework and review would be required. The highest inspection level a product could obtain was "ACCEPT AS-IS". An AS-IS was perfection: no functional errors, no documentation errors, no spelling mistakes even.
In the nearly 500 inspections we conducted during this project only one person on the team ever got an AS-IS on any product.
That was Harold.