Slashdot Mirror
Software Craftsmanship
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.
I have read this book.
While I liked it, and found it a nice framework in which to hang many thoughts on, I would recommend 'the Pragmatic Programmer' by Andy Hunt and Dave Thomas over this book. McBreen actually quotes that book so often in this one that I often wondered, "so, what was the point of this book then?"
There is only one book that preaches a methodology that I have found useful (and I have read several), and it is more of a programmers cookbook than a strict methodology. Design Patterns from Gamma, Helm, Johnson and Vlissides. It gives you exactly what you need as a programmer: the ability to communicate volumes of information about your system to me with a few key words. For example, if you tell me that your logging system is a Singleton object, I immediately understand its' place in your system and how to use it.
std::disclaimer<std::legalese> sig=new std::disclaimer; sig->dump(); delete sig;
Bruce Weide of the Computer Science Department of the Ohio State University has been working for several years on a way to introduce software engineering principles to first year computer science students. It's an interesting read (albeit one that was forced on me for my classes) and is available for download here in pdf format.
My family used to employ two carpenters. One was the gung ho type, always rushing around, cutting up boards, hammering, always on the go *doing* something. He was also relatively cheap.
The other guy was the typical old New England carpenter. Rarely spoke, and then in as few words as possible. He moved painfully slowly, almost like he was drugged. It seemed like he never did *anything*. If you walked in on him unexpected 19 times out of 20 you'd find him chewing on a pencil and staring out in to space.
He also cost twice as much as the other guy, so we were paying twice as much an hour to "get less work out of him."
Well, come the end of a project guess who turned out the most "product" for the least money?
Yep, the old slow guy. Think twice cut once works.
What's more, the stuff "Old guy" did is still standing strong 35 years later, and still drawing comment about the beautiful craftsmanship in our house.
Mr. "Works a lot"'s stuff has all had to be torn out and redone, in more modern, and thus more expensive, dollars.
I used to be head mechanic in the largest bicycle shop in New York State's Captial district. The boss would look at new bikes I put together and whistle, declaring, "I should charge every customer $10 for your assembly jobs."
Then he'd go out and hire some hack (literally, a cab driver) to throw bikes together for $5 each. Then he'd sell the bike, and with an impatient customer waiting ask me to "prep it."
Any bike I built didn't need "preping." If I put it on the floor it was ready for Lance Armstrong to get on and ride out the door.
These cabbie built bikes I had to take apart and reassemble, a job that took three times longer than had I been assembling them out of the box, while a customer stood tapping his toes. And the boss had to pay my high hourly to do this.
At one point I went to him and said, "Look, how about letting me assemble all of the bikes and you charge ten bucks *less* for them. You'll save money."
He never did get it.
I don't work there anymore.
For the most part, and I realize there are exceptions, being a craftsman means being selfemployed.
It's a rare boss who really pays you for the value you bring to the company. What they really want is people who make "the fur fly," even if all that does is make a bloody mess.
KFG