Software Craftsmanship - The New Imperative

At the 12th annual Jolt Product Excellence and Productivity Awards the book won a Productivity Award.

The book is now published and is available from Amazon and local bookstores. A Japanese translation is now available from amazon.co.jp, thanks to the hard work of Masaaki Murakami (who also translated The Pragmatic Programmer into Japanese).

Software Craftsmanship is a metaphor that can radically transform the way that we create and deliver software systems, with implications for the way we develop software, manage teams and deliver value to the users.

One of the classical problems in Software Engineering is getting engineers to consistently use effective methods, writes Watts Humphries in "Why Don’t They Practice What We Preach?". For smaller teams, Craftsmanship is a more appropriate metaphor than Engineering for getting developers work more effectively. Craftsmanship has been a model that has been used throughout history to effectively develop and disseminate arts, crafts and technology. By taking a sideways step towards craftsmanship maybe we can eventually advance the state of the art so that we can truly talk about Software Engineering.

• When you look at software, do you get the feeling that it has been developed without adult supervision?
• Is software more critical to your business and yet becoming bloated and buggier?
• Are projects taking longer and delivering less than promised?
• Can you tell when a software project is going off track?
• Is licensing software professionals really going to make any difference?
• The "software crisis" has existed for years and there is still a shortage of good software developers, because mechanical metaphors for software development don’t work.
• Software engineering has fixed many of the technical problems, now we need to focus on the social and cultural aspects of software development
• Extreme Programming works by paying attention to the craft of software development, on what developers do on minute by minute basis
• Software Craftsmanship allows developers to creatively blend Art, Science and Engineering to deliver great systems

This book is unique in that pays attention to the new reality of software development - People are the most expensive resource. Unlike practically all other industries, software is becoming more, not less labor intensive. As the cost of computers has fallen, and computers have become pervasive, our model for developing software has not adjusted to match these new realities.

Looking back into history, the problem of expensive labor and arcane skills was handled by Craftsmanship, with beginners being apprenticed to the craft. By prematurely adopting an engineering metaphor, the software industry has deskilled developers before it has found a way to create an effective software factory.

This book is a call to arms to say that we must insist that developers really know their craft before we trust them to create systems for us.

Some Interesting Ideas to play with before you read the book

• Software Craftsmen should sign their work. This will enable them to build up a portfolio of applications that can be a basis for their reputation. This will allow the software industry to move away from the various interview games that are played and instead base hiring on an audition model (page 144).
• Once you have hired the lead Software Craftsman for you project, let that person hire the rest of the team. Who they hire will let you know a whole lot more about whether they are going to successfully deliver than any amount of time spent in interview games.
• Software engineering was once characterized as being aimed at "managing hordes of 'average' programmers working on large teams that continue for years". Software Craftsmanship in contrast is about exploiting the productivity differences between individuals and using really small teams of good developers. If companies do this right they can afford to pay great developers what they are worth because they will stop overpaying for average talent (page 61).
• Start exposing the fallacy of good enough software. Bugs do not infect software and the cost of removing bugs does not increase as we eradicate the bugs (page 56).
• Licensing of software developers is an illusion, it is an attempt to fix the wrong problem. There was a very good reason why the ACM withdrew from the attempt to define a Software Engineering Body of Knowledge.
• Software engineering is the wrong metaphor for the majority of software development projects. By encouraging us to use a mechanical metaphor we end up making mistakes because it tricks us about the true nature of software development - that it is a social, intellectual activity, not a mechanical one. Small wonder then that the Mythical Man Month problem still exists, the way we talk about software development encourages us to think about "plug replaceable programming units" and hiring a six pack of Java programmers. For small projects we have to realize that the classical division of labor approach just does not work (chapter 3).
• We must reverse the decline in the quality of developer training. Learning software development is not the same as being taught how to program. Apprenticeship is more effective than training to learn a craft, since it is more about learning than it is about teaching. Apprenticeship deliberately avoids the "learned helplessness" of the schooling model by making the apprentices an integral part of the software development team (chapter 12).

Some reviews

Robert Martin of Object Mentor Inc. posted the following on Usenet

McBreen hits the nail on the head! This book is a MUST READ for all CxOs, VPs, Directors, Mangers, and Software Engineers. It will change the way you think about the software development industry and profession.

In Software Craftsmanship, McBreen exposes the weaknesses of our current system of software engineering, and proposes an alternative model based the older apprentice/journeyman/master model. McBreen makes the point that building a software project is not akin to product manufacturing. We don't have factories that stamp out software. Rather we have groups of people trying to massage software into place. McBreen likens successful software development to blacksmiths, or silversmiths. To McBreen, software is a craft that takes years to learn, and more years to master. The only way to properly learn the craft is to be taught at the side of a master.

McBreen's thesis emphasises something that is missing from software development today: attention to quality, and attention to expertise. The dotcom frenzy saw thousands of startup firms throwing young untrained bodies at complex software projects. The idea was that a programmer is a programmer is a programmer. The more you have, the faster you get done. McBreen counters this concept by showing that large software systems are better built by small teams comprised of masters, journeymen, and apprentices, than by large teams of plug replaceable programming units.