Software Craftsmanship: the New Imperative

I had been looking for a book that captured some of the ideas that had been revolving round my head for the last couple of years.  I’ve been involved with a few software processes in my past and none of them really solved the problems they claimed; some processes made improvements in some areas but inevitable cost in other areas. Today, I manage a small team, and things like CMM just seem so heavy for a small group of dedicated programmers, testers, documenters, etc. Software Craftsmanship: The New Imperative is directed at this conundrum.

One underlying assumption of this book is that most software development processes, such as CMM, were developed due to problems attacking large-scale (more than 10 person-year) projects. Many, if not most, software today is written by small teams of 2 to 10 developers, with a goal of reaching production quickly, typically 3 to 6 months. Software processes are often aimed at controlling the communication flow, which is a severe problem in large projects. Small teams don’t normally need that much communication, and so such controls can get it the way of building great software.

Pete McBreen suggests we look back to Medieval times and consider the craft guild analogy for software development in small teams. “We must insist that developers really know their craft before we trust them to create systems for us or with us.” McBreen suggests that we utilize fewer, but better trained and experienced, developers to build applications for our customers, and that the correct training method includes both traditional traning and, most importantly, an apprenticeship process.

Craftsmen work directly with their customers: “Develop a close working relationship with a small number of users, and then create the best possible application for these users.” “Having developers sign their work is a fundamental part of craftsmanship because it completely changes the mindset of the people involved in the development process.”

When we select developers for our teams, we should not only look at price (salary). McBreen includes one of Demming’s “Fourteen Points”:

“End the practice of awarding business on the basis of price tag alone; instead minimize total cost in the long run.”

Reputation for delivery has a profound effect upon quality and satisfaction with the delivered result.

One problem we’re facing today is that we are paying to much for lightly skilled labor. Craftsmen should be paid appropriately for the value they produce, but so should journeymen and especially apprentices; apprentices are getting an opportunity to learn a craft from the ground up and will not be very valuable for a period of time. Software mastery involves using stable technologies and being able to learn new technologies when and as needed. “We can, however, expect true craftsmen to become productive quickly in any technology that is reasonably close to what they were already familiar with.” “Achieving mastery of the craft of software development takes at least 15 years – probably longer. Of course, one can cite many examples of very young, talented programmers who have created fantastic programs, but software craftsmanship entails much more than solo programming. Talent is not the same as mastery… It involves taking on the responsibility for maintaining an application for users and nurturing other developers so that when the time comes to move on to other applications, they will be ready and able to step into the maintainer’s role.”

“Managing great developers is a pleasure and a privilege… They (managers) know that managing software development projects is not like managing mechanical projects… Most of all, good managers appreciate the value of a team that can deliver… Good managers also know that projects and systems have a certain rhythm. Teams can push themselves to deal with external demands, but the push must be followed by a time for rebuilding reserves.”

There is a good discussion of the procession of apprentice to journeyman to, sometimes, craftsman (some people will stay forever journeymen just as people did back in Medieval times – that’s not a bad thing but a good thing as all levels are required to build a working, long-lived team).

I obviously liked the book – I hope you find this material and book useful also.


There are no revisions for this post.

Comments are closed.