For software development professionals interested in quality code

QualityCode Book Review: Software Craftsmanship

Review by Kevin Smith

I just finished reading the book "Software Craftsmanship" by Pete McBreen. It is a very provocative look at software development, mixing some old-fashioned common sense with some pretty radical ideas. I'll just try to give you a few highlights, and I recommend that you read it for yourself.

As an aside, I wish the word itself were "craftspersonship", but I can understand why it is not. There are other unfortunate terms such as "journeyman" and even "master". Oh well, such are the limitations of English.

McBreen claims that the whole concept of "Software Engineering" was invented in response to huge hardware/software projects, such as the classic IBM mainframe operating systems, or large military weapons applications. It is optimized for these long projects that involve hundreds of developers (1000+ staff years of effort), and dependencies on external deliveries (such as the hardware itself). He believes it is completely inappropriate for typical modern software projects (up to 100 developer-years of effort).

The alternative that he proposes is based on traditional crafts such as blacksmithing. The developer takes personal pride in the work, and stands behind it after it is delivered. She develops relationships with the customer, and relies on her reputation to get more work. She focuses on "people" issues, both within the team of developers, and also with the customer and end-users. She also takes responsibility for training her successors, and for building a solid team that can work together for years at a time.

This is unlike the move towards licensing software developers. Under a licensing model, nobody has to take responsibility for whether a developer is actually effective or not. Unlike an electrical system, nobody can look at a work in progress and determine whether it is "to code" (pardon the pun) or is a safety hazard. Under the craft model, the reputation and portfolio of a developer are the keys to evaluating them. Software is still more art than science (and will be for a while longer...perhaps forever). He believes we need _more_ variation in our software processes, not less. The whole idea of universal "best practices" is a bit dangerous.

Under the craft model, people start as apprentices, then become journeymen, and finally become masters. It is a lengthy process, and assumes that individuals will often work together on project after project. Journeymen benefit from working with multiple masters, to gain the breadth of experience necessary to set up their own shop. Although it sounds like a contractor model, he actually believes that developers should generally be employees, to give them additional incentive to do good work.

He mentions that top-notch developers can single-handedly "save" a project, or cause it to be far more productive than it would otherwise. Many studies have shown that the best developers are ten times as productive as the worst. Many of the best applications have been developed by one person, or a very small team. He argues that instead of hiring a team of 50 warm bodies to develop an application, you should hire five really good people, and pay them as much as you would have paid the 50. After all, that's how much value you're getting, plus you're paying less in overhead (e.g. office space), and you are also dramatically reducing project risk, because large projects are the most likely to run out of control.

On the flip side, inexperienced developers are dramatically overpaid these days. I assume this has become slightly more sane in 2001, but I know it was absurd in 2000. There is room for apprentices, but not very many on any one project. Each master might have a direct apprentice or two, and might manage a few more through the journeymen on the project. The apprenticeship model is a very effective long-term way to turn inexperienced developers into highly productive masters.

He believes that the best indicator of future success is past achievement. Thus, if you have a successful team in place, do what you can to keep it together. When hiring, prefer someone whose work you already respect. Next best is to rely on the recommendation of a software craftsman that you have worked with. If you have to hire without a recommendation, look for someone who has maintained a product through several major releases. This is the only way a developer can appreciate the consequences of various coding practices--you have to live with your own mistakes (and mistakes of others) to understand the importance of quality, clarity, etc.

Interestingly, he suggests hiring a single master developer first, and allowing that developer to build the rest of the team. This puts the responsibility for choosing the best people in the right place, and allows the team to gel faster.

He closes with this bit of wisdom: "Software development is meant to be fun. If it isn't, the process is wrong."
Posted 2002-01-29