Recently, somebody recommended me to take a look at Software Craftsmanship, by Pete McBreen, as a good treatment of software engineering versus software craftsmanship as approaches for software development.
The theme is indeed interesting, but I was surprised to see how badly the book is written. McBreen, granted, does a decent job of presenting the main arguments for both sides–which is more than you would expect from a proponent of a specific approach–but he also repeats those same arguments endlessly. I don’t know how an editor managed to let something like that happen, but if the incessant repetition were to be eliminated the book would lose at least three quarters of its almost three hundred pages.
McBreen’s argument is simple: Software engineering is appropriate only for huge projects (those is the 100 developer-years and above). For simple projects, needing faster development and no critical hardware infrastructure, the old concept of craftsmanship is much more interesting: a master craftsman running a team of journeyman and apprentices.
I agree with the arguments and many of the other conclusions presented my McBreen. In fact, to the extent I’m concerned, that’s exactly the way I’ve been running my own small company. The results, so far, have been excellent.
Mane people reading the book, however, will quickly give up after reading two or three entire chapters essentially saying the same thing. They won’t look kindly also, to statements like the one below:
Software craftsmanship is the new imperative because many members of the software development community are stating to chase technology for its own sake, forgetting what is important.
The fact that the second part of that sentence is painfully obvious and that the relationship between the first and second part is clearly a non-sequitur doesn’t seem to bother McBreen, tough.
Nevertheless, much of what McBreen is talking about is valid and necessary, as when he describes how good enough software is not really good to users or the industry. Some of this analysis of the prevalent (and wrong) metaphors–like car building versus car design–were interesting enough to motivate me to finish the book.
Ultimately, the book is necessary and part of one of the most important debates taking place today in the industry. I’m afraid, however, that many readers will abandon the book after a couple chapters after being put off by McBreen’s redundant style. More’s the pity because a good editor would made the book the new Peopleware.