Renaissance Software Development

I recently read a blog post called A Guide to Hiring Programmers: The High Cost of Low Quality in which Frank Wiles makes the case, when staffing a software development project, to hire good coders even if it means sacrificing everything else. Serendipitously enough, I also read a book called The Business of Software by Erik Sink in which the choice, at least for small ISVs, is to hire developers instead of programmers. Developers code but they also can do other things such as design, model, and interview customers in order to capture specifications or defects. I am interested in these different styles or philosophies in software development because of my long history of experience in the field.

Frank advises not to even bother with the requirement that they are familiar with the target programming language or application platform stack. He also advises to let them telecommute 100% of the time if they want to. His reason for all of this is the claim that a good quality programmer will be 10 times more productive than an average coder. My guess is that the big boost in productivity will come once they learn the environment, etc.

Erik makes the case that a good, well-rounded developer will advance the project faster than a hot code specialist. If you had to choose between an average developer and an excellent programmer, then you should pick the developer.

It's really the choice between generalists and specialists which, really, is no choice at all. A project full of specialists may produce something brilliant but it is unlikely to advance the stated goals of the organization. A project filled with generalists might produce something completely on target but with a very lackluster execution. I say, let's embrace the genius of the and over the tyranny of the or and staff the project with both. Use the generalists to keep the project nimble and on target. Use the specialists to quickly solve any advanced technical problems that will arise. You wouldn't play chess with all bishops or send out nothing but running backs on to the football field. Why would you do the same thing in software development?