Managing software engineers

I ran across this article on Managing Software Engineers the other day.  The author, Philip Greenspun, has some interesting ideas, but for the most part I disagree with his assessment.  My experience with making programmers work 60, 80, or more hours per week is that they burn out relatively quickly.  I’ve been on a 12-month “Death March” project that suffered more than 100% turnover.  Not a single member of the original team remained by the time the project was canceled.  I’ve seen other projects with similar turnover rates.

In my experience, the key to programmer productivity is making sure that the programmers are actually working on their assigned tasks.  Without supervision, programmers tend to head off into uncharted territory or spend their time surfing the web, playing games, or goofing off with something else behind the terminal.  I’ve found that I can keep a programmer focused by creating a busy but realistic schedule with achievable weekly milestones.  This not only keeps the programmer focused, but also helps spot someone who’s either not working, or needs some assistance and further training.

The article talks a lot about “great” programmers.  In my experience, “great” programmers are few and far between.  There are a lot of hotshot code jockeys who can spit out an amazing amount of almost working code in a very short time, but they are seemingly incapable of coding to design, testing their code, or documenting it.  Invariably, somebody has to rework the code to make it work.  These hotshots end up being far less productive than a “merely good” programmer who takes his time and delivers a fully functional, tested, documented, and bug-free milestone.  I’ll take a room full of hard-working, conscientious, stable programmers who work 40 to 50 hours per week over a couple of Prima Dona hotshots who do what they want when they want and usually deliver a pile of mostly useless code.