I just finished reading Software Craftsmanship: The New Imperative (Addison-Wesley, 2002) by Pete McBreen.

Software Craftsmanship is a new attempt to define how great software should be developed, in contrast to the classical software engineering approach.
Pete McBreen sees that software engineering has borrowed many of the process, habits and terminology from the mechanical and manufacturing world.

Above all, for Pete, software developing is more of an intellectual, social task than it is a mechanical task. And that requires a new approach.
On the first chapters Pete takes a look at what is wrong with software engineering giving some background at the succession of events that have led software engineering on what it is today. Pete argues whether division of labor can really help software development or whether a ‘one-size-fits-all’ methodology really exists. This document is particularly insightful: Why they don’t practice what they preach?

After that, Pete introduces the concept of software craftsmanship. Software craftsmanship aims to create applications using small, highly skilled teams. Rather than attempt to build really large, monolithic applications, the craft approach seeks to build small applications that can then build on and enhance each other. However, software craftsmanship is not a replacement for software engineering, but rather a complement to it. In Pete’s words: “Scaling down software engineering to deal with smaller problems is just as hard as scaling up the craftsmanship approach and just as inappropriate”.

As in the old crafts, Pete borrows the metaphor of an Apprentice, learning from a Master, making his way to a Journeyman, and later, to a Master himself.

Coming to think on these terms Pete McBreen suggest the following principles that characterizes Software Craftsmanship:

  • Small teams of good developers are more productive than large teams of average developers.
  • Developing great software means paying attention to detail, as in old crafts.
  • Do not focus on specialization. All members within the team, should understand the domain of the problem. There should not be anyone specialize in a specific part of the project, so then, no one is really indispensable.
  • Code is reviewed by all developers, so as knowledge is spread among the team.
  • Software should be developed as if it were to last 10 or 20 years.
  • Maintenance should not be regarded as a low-level task, as taking over a project is proof worthing trust and respect.
  • Take credit for your work.
  • A master never leaves a project, as she takes credit for her work. Instead, it trains a successor.
  • Perpetual learning.
  • Constant communication with customers. Input from users is as important as the development process.

Many of the ideas suggested by Pete McBreen are in fact very similar to some of the ideas proposed by Agile methodologies: small groups, constant communication with clients, code review, etc. In fact that is something that the author himself states in the book:

“Agile Methodologies focus attention on the individuals in the software development team and the quality of their interactions with their customers and users. In doing so, they provide a good fit with software craftsmanship and another voice warning about the hazards of the software engineering approach. “

Other ideas proposed by Software Craftsmanship have been present within the free/open source communities from long time ago. The idea of taking credit for your work, spread the knowledge of an application among the team or the idea of training a worthy successor when the master leaves a project. Once again, Pete highlights these similarities in the book many times.

Although the idea is provocative and maybe need refinement I found the reading interesting. I liked very much the background exposed at the beginning, when McBreen established similarities between classical software engineering and industrial engineering. The idea of growing from apprentice to master seem to me more like a good metaphor of the path every engineer should take in their career, struggling for improving and continuously learning.

“Software development is meant to be fun. If it isn’t, the process is wrong“
Peter McBreen