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

Huh?

[sulli]

Instead I found myself angry at the author for his strawman arguments, illogical conclusions, unfounded assertions, and irrelevant asides.

Don't read slashdot much, eh?

Read Pragmatic Programmer

[bokmann]

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?"

Re:Read Pragmatic Programmer

[cybermace5]

I would recommend 'the Pragmatic Programmer' by Andy Hunt and Dave Thomas over this book.

Such a multi-talented man Dave was. I still prefer Wendy's over any other fast-food restaurant. So the 'Pragmatic Programmer' has an extra-spicy approach to coding?

*ducks*

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).

Re:From recent experience

[Zordak]

Actually, bad variables are great job security. Right now, I'm working on a utility that will take your finished code and replace all of your good, intuitive variable names with "varXXXXXXXX" and remove all of the comments. It saves a password-protected "undo" state, so that as long as you are on the project, the code is maintainable. As soon as you get canned for somebody cheaper, Mr. No Experience goes crying to mommy.

Version 2.0 will replace all of your comments with your phone number and an increased salary demand.

Comparing programming to "real world" endeavours

[binaryDigit]

I always find it amusing to read about people who try to compare programming (or software engineering, or whatever) to things such as house building, or even more general like "master craftsman", apprentice, etc. One of the biggest problems facing developers today is the overwhelming complexity of the software being created and the environments they are being created in and the pressures of getting said software done in a particular timeframe.

If one MUST use some real world analogy, then imagine wanting to build a dresser. You come up with the requirements, must have four drawers, have certain dimensions, be made with a certain type of wood and be stained to look a particular way. So you start buying lumber. But wait, no one carries just the right type of lumber you want, so you run out and cut your own tree down and make the lumber yourself. You decide to dove tail the drawers, but the dove tail rig you have doesn't quite fit, so you kinda work around it and get "good enough" dove tails. Uh oh, you never checked with your wife on those dimensions, she wants something 6 inches wider, gotta take those drawers apart and make wider ones, do you cut more trees down, or do you patch an add on to the existing pieces? That last one put you behind schedule, so now you don't have time to actually check your work completely as you go and your carpenter friend Bob has a baseball game to go to, so he can't help with that tricky scroll work you need to do, guess you'll just go online and just copy what someone else has done. etc, etc.

Not to mention that few software projects have such simple requirements. This dresser has to actuall fold the clothes for you, let you know how many socks are present, pick your wardrobe for the day AND it has to look pretty, interface nicely (dooh, made those knobs too small to grab), etc, etc.

And lets not forget one of the biggest project killers, you decide to build this dresser with four of your friends, each doing a different part. And dang it if those drawer openings are too small. And the trim around the edges are 1/4" smaller than the trim used for the mirror, and those pilot holes are 3/8" but your using 5/16" screws.

You get the picture. Nothing like this happens in the real world, software is a completely different beast and to contrain it by using realworld analogies might push a few books, but it's not making software engineering or the software being produced any better.

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.

No big surprise here

[fw3]

1. That McBreen is a co-author of 'Questioning extreme programming'

2. That the /. review(sic) is incomplete, biased and (imo) less useful than the reviews on Amazon/BN.

His credentials seem ok, the excerpts looked interesting and relevant and I think his approach is a viable one (which is not to say it's the only or best one for any given circumstance).

Modern software engineering(sic) doesn't seem equal to the challenge that many (cough-MS) organizations developing software emphasize absolutely as many features as can be crammed into the deployment space, with reliability criteria seemingly like "if it's not so unstable that the customer will ask for his money back, we ship it".

Ok that's the current market and goodness knows people keep buying and writing bloated, buggy software is by no means limited to commercial/priprietary, it's become all too common in free/oss projects also. (See my related views about that).

The mantra that seems to drive the market is "More features". Personally I beleive the best programs result from the alternate view: "The best program is the smallest program that fits the need".

So wherever the statement "If buildings were constructed the way software is constructed, the first ant to come along would destroy civilization overnight" remains true, I think the applicability of "software engineering" is (nil).

My notes of Software Craftsmanship

[Anonymous Coward]

I enjoyed this book, even if I didn't agree with everything that Pete had to say.

Notes of interest:

• Master programmers (craftsmen) should be paid more than many programmers.
• Treat software as capital assets - it costs money to replace.
• "Single vendor and new languages are always risky". Avoid "bleeding edge" technology (anything that is new to the team) (p. 148). Exercise caution when using it. More time is needed to evaluate and get familiar with new technology. More QA time is also necessary.
• The ideal learning time is Tuesday or Wednesday -- it allows people time to try out new ideas (before they forget them over the weekend). Do tutorials and seminars according to the team's needs -- Just In Time.
• "Craftsmanship diverges from engineering in that it emphasizes personal responsibility and decentralization" -- p. 179
• "Talent matters more than the process that is used". How do people get "talent"? They pay the price to learn, and should always be learning.
• There are no one-size-fits-all software development methodologies or processes -- p. 22
• Java is considered "high-risk" (p. 160) -- only use it for application lifetimes of five years of less. (Wow, this is quite a claim).
• Asserts that small teams of master craftsmen are more effective than large teams.

- JWR