Daniel Irvine on building software
Book review: Software Craftsmanship
27 May 2014
Software Craftsmanship: The New Imperative by Pete McBreen is a self-proclaimed “call to arms” for the software development community. The book promotes the idea that for a large majority of software projects, the de facto development practice of software engineering is ill-suited and we should instead be using a more artistic and craft-based approach--namely, software craftsmanship.
At 208 pages, it could be read across a couple of evenings but is also broken into independent chunks that lend themselves well to re-reading. It’s the sort of book that you could keep prominently on your bookshelf, picking it up when the mood takes you, flipping to a random page and taking five minutes to reinforce the insights presented.
The book has a number of central themes running through it which crop up repeatedly, the first being that software engineering is a poor choice for anything other than extremely large systems. Software engineering--large teams made up of distinct roles--harks back to scientific management practices of the 1920s and 30s. This process may have worked for the first software builders--which tended to be large, wealthy organizations--but scientific management has fallen out of grace in other industries. Despite this, it mysteriously persists within the software industry.
A subsequent theme is that craftsmanship is not new--many of the studies and texts cited are from the 1980s and 90s, when the world started waking up to the failings of software engineering. One study that the author refers to is the Borland Quality Craftsmanship paper from 1994, which described how a very small team built the well-known spreadsheet application Quattro Pro in the late 80s. They were essentially following a software craftsmanship approach, and this was 25 years ago.
The maintenance phase of application development also comes under scrutiny. At times the author gets pretty heated, using the words “crazy” and “stupid” to describe software engineering’s view of maintenance, since it treats maintenance as a relegation zone for poor programmers who quickly cause prized software to become “legacy.” Later on he says “maintenance is the most important part of the life of any application”, and talks about “planned obsolescence”, the software engineering idea that software has a short shelf-life. The author dislikes this idea immensely and provides many counter-examples for why this isn’t the case--particularly in the open source community.
In Chapter 11 there’s a fascinating comment about COBOL. The author is arguing that this is a language that is still alive-and-well despite attempts to kill it. The question the author poses is: why are we trying to kill it? Why is it viewed as legacy, when it still provides value and is clearly an incredibly successful language? I’d never thought of COBOL in quite this light--perhaps I’ll start learning it...
Ageism in the industry also comes under attack, and quite rightly so. It’s a shame that this problem only seems to be getting worse in the 21st century. Large software companies like Facebook, Google and Microsoft compete to snap up grads from the top universities, paying insane salaries as if these programmers with no professional experience are far more valuable than our experienced programmers with 20, 30, 40+ years in the field. Software engineering, of course, pushes these masters into management and architecture. The author points out that this simply means we lose valuable experience which is why we as an industry continue to repeat common mistakes. Perhaps if we valued our older and more experienced worker more, we’d build better software. It’s great insights like these that make craftsmanship such a compelling vision.
Humility and willingness to learn is also highlighted throughout the book. A true craftsman will always be willing to learn from others, apprentices included. This is not the ethos that software engineering fosters--many of us know this from experience, unfortunately.
The book offers a few insights into how to be a craftsman, such as being a polyglot, but by and large it leaves such practical topics to other books. This book is really a manifesto to convince you, your boss and your team to try the craftsmanship approach.
You should read this book if you’re a craftsman, or an apprentice craftsman. You should absolutely read this book if you’re a software engineer. You’ll be better off for it.