Software Craftsmanship by Pete McBreen is yet another book on software crafting ideals and practice. This one in particular, however, focused more on the differences between the idea of software craftsmanship and software engineering. It approached the terminology and how each affects management and programming methodology.
The author considers software engineering and craftsmanship to be two very different ways of tackling two radically different problems. Engineering is a highly methodical and procedure based style for large problems with high risks. The example he used was NASA. The projects are massive and involve teams of great size. The standards for the code dwarf that of commercial projects because of necessity. Due to the circumstances and context of the problem, the engineering approach may be the safest and most effective.
But for other, smaller projects, craftsmanship is superior, McBreen believes. Craftsmanship puts more power in programmers, giving them more understanding of the entire structure of the system and allowing them to influence it more effectively. Engineering hampers the creative process and removes the power of people from the project. Craftsmanship is supposed to use people effectively in order to solve a given problem. Not all problems are created equally and set solutions don’t exist, so a creative and critical-thinking aspect is needed from the people who are working on the particular project. It is more ‘artistic’ in McBreen’s world.
I think I agree with McBreen on the distinction between engineering and software crafting/programming. I’m not sure if engineers would feel the same, as he kind of implies that they are not uniquely special or can make that great of a difference. Like the returns of a great programmer is much greater than that of a great engineer with this reasoning. It probably is true in some ways–programming has more flexibility and is subject to more rapid change than traditional engineering fields so the particular individual needs to be more adept and have more control over making choice based on experience and understanding of both the project system and the current programming ecosystem.
His point about the, ugh, mild useless-ness of college with respect to software development really struck a chord with me. When he was saying that what being taught in universities was more theoretical than practical, all I could think was yes. Agreed 100%.
I can’t say I completely agree with McBreen on all his points though–there are some distinctions and claims that he makes that I’m not sure hold up all the time, but for the most part I think he is on point.