Software Craftsmanship

kaisyain writes "When I was a kid we moved into an old Victorian house. From the street the house looked impressive and fascinating. When you got up close, however, you noticed the paint was peeling, the widow sashes were rotted away, doors couldn't open or close because they didn't hang true, and at some point someone had cheaply redone the kitchen in a style that was very much not Victorian. Pete McBreen's Software Craftsmanship reminds me of that house." Read on to see if you agree with kaisyain's withering review. Software Craftsmanship: The New Imperative author Pete McBreen pages 192 publisher Addison-Wesley rating 2/10 reviewer Justus Pendleton ISBN 0201733862 summary A good start with a terrible finish that answers few of the questions it raises.

The back of the book claims that it will present an alternative method of software development, "a craft model that focuses on the people involved in commercial software development." McBreen offers his "software craftsmanship" model up as an alternative to the mainstream "software engineering" model that dominates much of the literature. It is a position that I am personally sympathetic too, so you'd think I'd be favorably disposed toward the book. Instead I found myself angry at the author for his strawman arguments, illogical conclusions, unfounded assertions, and irrelevant asides.

The book starts off well enough. McBreen points out that, historically, software engineering literature and theory have been dominated by huge projects from the military and government and small, complex, esoteric projects from academia. Neither of those extremes reflect the reality of developing applications for most developers today. McBreen offers up a method of working patterned on craftsmen of old, with a basic breakdown of master craftsman, journeyman, and apprentice.

All of this sounds well and good, but how about some details for what this means in practice?

First we have to wade through some arguments against licensing the profession. (Although craftsmen of old did that all the time, maybe he doesn't want us to extend the metaphor too far.) And then we have to read about how to be a good user. (The back of the book says it is written for programmers, so why do I need a section titled "Stop Choosing Developers Based on the Lowest Bidder"?)

As you're reading chapters like "Becoming a Software Craftsman", "Learning from Software Engineering", and "Design for Testing and Maintenance" you slowly begin to notice that none of this has anything to do with software engineering per se. After all, what is software engineering? McBreen gives a definition on page 7 taken from the IEEE:

Software engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software.

He promptly forgets about this definition in his zeal to set up strawmen for his software craftsmanship model to knock over. "The software engineering view states that COBOL is a dead language with no future." "Unlike software engineering, software craftsmanship takes a long-term view of things." "A key difference between software craftsmanship and software engineering is the emphasis that craftsmanship puts on learning and coaching." "Software engineering, therefore, has to deal with the problem of developing software where incremental development and evolutionary delivery are not feasible strategies." He suggests that journeymen review the work of apprentices and that master craftsmen then review the reviewed work: "Although the software engineering paradigm might consider this type of secondary review to be a waste of time, it is an essential part of practicing any craft." "You cannot do software engineering on a low budget...software engineering projects take a lot of time...software engineering denigrates anecdotal evidence."

Where does he get this stuff from? Did I read that right, he thinks formal software engineering would complain about too many code reviews? I must have missed that issue of IEEE Software.

He seems to think software craftsmanship is somehow vastly different from this thing he keeps calling "software engineering" but anyone even vaguely familiar with software engineering literature will have a hard time spotting any actual differences. On page 113 he seems to be against "code walkthroughs" although I fail to see how they are any different from "A master craftsman...[inspects] everything that the journeymen and apprentices create." On page 124 he rails against software engineering's use of "best practices." He doesn't seem to understand that "best practices" are nothing more than anecdotal evidence and an attempt to gather and disseminate information of "master craftsmen."

This symptom is worst in the concluding section, "What to do on Monday", which is intended to be a set of things you can do to end your slavish attachment to software engineering and start out on the path of software craftsmanship. What revolutionary things does he advocate that software engineering must clearly be diametrically opposed to? He suggests we carefully evaluate the portfolio of interview candidates; pay talented staff extremely well, perhaps even more than managers; we should design for testing and maintenance; pay more attention to usability over glitter on user interfaces; create a learning environment to encourage perpetual learning.

What does any of that have to do with software engineering vis a vis software craftsmanship? Is there some reason I can't pay my developers extremely well and still have a systematic, disciplined process?

McBreen's entire premise is flawed because he doesn't seem to understand what software engineering is. His argument seems to be with a specific process, not with software engineering itself. He offers some useful advice but none of it is earthshaking and none of it is really an alternative to "software engineering." Indeed, none of what he talks about is especially new, either. It is basically the same "surgical team" model that Fred Brooks described decades ago, something he alludes to but never outright acknowledges and explores.

McBreen makes a lot of smaller missteps along the way that damage his credibility but they are really too many to enumerate. At the end of the book, you not only don't have any clear idea of what makes software craftsmanship different from a well-run software engineering shop, you also have no clear idea why you spent $29.99 on a 180 page book softcover book.

Interested readers can purchase Software Craftsmanship from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Comments

What he says

[The Terrorists]

can be said about any craft or art pursued by human beings. The real question is, why will this book sell? Because coders, like other craftspeople, will take a schematic quick way to solve the problem over the tediousness and attention to detail and painstaking slow work that any quality craft requires.

This is also why stuff like Extreme Programming and other strategies become popular. There are many ways to quality - all of them are task specific and slow. There is no magic pill.

Re:What he says

[ReconRich]

Because coders, like other craftspeople, will take a schematic quick way to solve the problem over the tediousness and attention to detail and painstaking slow work that any quality craft requires.

Coders almost ALWAYS take the quickest way (on commercial projects) Why ? Because coders are evaluated on the basis of what they get done, and how quickly. Bug counts are hardly ever relevant; in a world where delivery schedules are the ALL IMPORTANT factor, a craftsman is a LIABILITY. Assuming he doesn't get fired for not meeting the same schedule as guys who throw something together as quickly as possible and then forget about it, His wonderfully crafted, nearly bug-free, easy to use application will fail miserably, because a dozen or so crappy applications beat him to market. Face it folks, the software buying world rewards those who
1. Are first to market
2. Control the market.

Craft helps neither first, or control. Hence, the people who fund software development DON'T CARE about it.

On the other hand, Open Source and Free Software do not have this kind of profit-maximizing strategy, hence these observations do not apply.

-- Rich

From recent experience

[phorm]

I've seen a lot of apps - especially web-based ones - that look great and are coded like crap. The problem with somewhat simpler languages, especially scripting languages, is that the ease of learning the basics often leads to some very undereducated programmers.
I don't consider myself a "professional" Perl programmer, though I've had several years experience, but even I can see when a large system is made up of a lot of little shyte.
Another thing one might notice in particular, is on group-programmer projects. The interface coding might be very nice, and then when one goes the the back-end modules that query mySQL DB's, etc... it's obvious that it was a different and less experienced programmer.

When I start seeing things like:
$stuff[1], $stuff[2]
$blah
etc
it scares me. If code isn't going to be commented, at the very least the variables can be intuitively named so as to make sense, and using arrays of hard-to-determine crap for no reason is just bad (at the least, use named hashes, or just normal vars).

What I tell my group

[jackjumper]

I run a small software group writing control code for semiconductor processing equipment. I read a lot of literature and what works for my group is:

- code reviews on every check-in
- lots of refactoring
- incremental releases
- constant testing
- individual 'craftsmanship'

So what do I tell my group? I tell them "any piece of code you write you should be proud to show at a job interview."

And I lead by example.