I expected this book to be about the craftsman aspects of writing code, that is, the actual writing of code from the point of view of a craftsman, much in the same way that a technical engineering book would describe how to build better products from metal. Instead, it is a personal diary of experiences, mostly about business practices that any mature organization would apply to recruiting, hiring, and managing talent.

In that sense, it’s a disappointment. But that is simply because of my expectations. For those developers who are just joining the workforce, this book provides insight into the workings of the business and examples of bad management.

There are three generations of software development according to Walker Royce [1]: 1960s and 1970s (craftsmanship), 1980s and 1990s (early software engineering), and 2000 and later (modern software engineering). This book appears to have gone back to the 1970s, but without any of the practical aspects of actually developing code, other than restating the agile process found in many other books.

Let me state my biases up front: When I read a book or prepare a briefing, I’m looking for actionable outcomes I can put to work or that my audience can put to work when they leave the meeting. I didn’t find that here. It’s a personal journey book. The book has no references or bibliography. Many of the stories are about bad management, and much of the content can be found elsewhere. There is some advice, but, as mentioned, it mostly relates to the author’s personal journey.

This book is focused on developers of software rather than the engineering of software solutions. The preface asks us to accept that the book is relevant to all software developers and every professional directly involved in a software project; however, without a specific domain, it’s hard to say if all software developers will find this book useful. My background is in software-intensive systems for space, defense, and enterprise information technology (IT). These domains are engineering focused and craftsmanship is certainly part of the paradigm, but engineered systems involve much more than craftsmanship.

So the first question is how applicable craftsmanship is if, as the preface suggests, it is mostly defined by extreme programming, with synergy from agile and lean. Lean certainly can be found in engineered systems, and agile is entering the domain of software-intensive systems, but the foundation of extreme programming appears problematic, since it is based on small (some would say very small) teams, an onsite customer, and very little in the way of requirements and architecture.

The book starts with a bit of history and the agile manifesto. A quick review of process-oriented disciplines and technical-oriented disciplines sets up the notion of agile. The conjecture that agile is about quick and short feedback loops and the suggestion that the quicker, the better ignores the business rhythm found in larger projects. This is a common gap found in agile books and practice that have not yet come in contact with software-intensive systems like enterprise resource planning (ERP), industrial controls, mission-critical systems, and the like. The business’s ability to absorb these quick and short feedback cycles is not addressed here.

Although the book contains good content, it is often a repeat of other topics with personal anecdotes sprinkled in. If the reader is expecting, as I was, a practical guide to building software as a craftsman, this is not the book.

More reviews about this item: Amazon