Product development cycles are riddled with problems. Sales people promise a great new, impossible Whatsit to customers then come tell you the Whatsit has to be built. Managers give engineers a delivery date and then ask engineers to size the effort. The engineers scramble, back burner the Hoozit project they were told last month was top priority, size the Whatsit and start strapping things together. Best efforts are made to tie it together, test it, fix it, and release it. Then they try to get their heads back around the Hoozit, excepting for fixing the Whatsit when it breaks.

One Great Programmer?
Tom Evslin proposes that one great programmer is worth those fifty good programmers working on Hoozit and Whatsit.

Cutting to the chase, he’s grabbed the pivot point of competing problems; a great programmer can be far more valuable than fifty good programmers, particularly if you need a slick, efficient system built quickly and in a sustainable manner; and a great programmer can be far less valuable than fifty good programmers if you need a large mess of code written quickly. Sometimes a business needs a large mess of code completed quickly and the only thing that will fit that bill is a decent architect and a bunch of decent coders. And money, but that’s beside the point.

Evslin does make some good points, though. His notion of fixing a budget but removing individual salary caps is interesting, but I think upper-management school is taught that engineers are interchangable, so this would not make any sense to them. More important, he stresses that throwing additional people at a problem adds additional complexities, additional interface inconsistencies, additional meetings — all sorts of kruft that goes away if you have just one “superstar” programmer.

Superstar Problems
But problems abound with that one superstar programmer. Businesses do not operate in the ideal vacuum of programmer space. They are ill-advised to bow at the feet of a single engineer with a well-earned ego. What if he leaves? What if he takes his ideas to build a competing business? How can you stop him? Threaten him? Will that work or will it buy yourself more trouble?

Coping with Really Good Employees
A better solution is to hire a couple really good architects, several really good programmers and test engineers, and if you need them, a bunch of good programmers. Then make sure you hire or train and promote great managers. Poor schedules are most often due to unreasonable demands from management or pressure from sales folk. Poor designs are due to little or no coordinated system architecture and design. Poor programming is due to laziness or even bad morale.

What’s missing from the process is discipline. Plan carefully. Permit realistic sizings and set schedules after you know how long it will take to build the thing. Keep some pressure to deliver, but allow for relaxed design and code reviews that involve all available engineers. Good engineers cut corners when quality isn’t encouraged, or they’re run ragged and aren’t valued.

Programmers can dream of being that one superstar with the superstar salary, and they might find a place in a small shop. For most companies building great Hoozits and Whatsits is a matter of hiring good people for the right jobs, allowing them to put the cart behind the horse, then respecting and valuing them and their work.