th H

 

 

   
Articles...

Copyright 2010 Corvus International Inc.  All Rights Reserved

Home      About Corvus       Contact Us       Articles/Resources       Clients          Affiliations  

That's what I thought when I wrote it.
There was a little bit of worry in the back of my head


                        Harold King (no relation to Bad Harold)
                        American Author

Commandment #11 of "15 Commandments to Curb Bad Programmer Habits":
Thou shalt not deviate from the "agreed" development approach
without a good reason that has been thought about.


                        Mark Collins
                        As published in SoftwareReality (link
)
  


ACM DL Author-ize serviceThe business of software: In praise of bad programmers
Phillip G. Armour
Communications of the ACM - Amir Pnueli: Ahead of His Time, 2010

Bad Harold                                       

Harold was a bad programmer.  A really bad programmerBut 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.

Harold's Postscript                               

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.

In Praise of Bad Programmers