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.
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
Bejaysus! did Microsoft build your house?
this sig steers like a cow. and i can prove it
Is Orson Scott Card behind this somehow?
Don't read slashdot much, eh?
sulli
RTFJ.
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*
...
It sounds like whoever wrote this review just got done with Philosphy 100 at the local community college and is eager to show off his/her stunning analytical abilities by bringing up every single fallacy mentioned in the class. It probably gave him or her a sense of accomplishment or something.
Robert
...and buy a copy of the "Extreme Craftsmanship" book that is sure to come out next year.
When you got up close, however, you noticed the paint was peeling, the widow sashes were rotted away,
If my house were full of bereaved women wearing decomposing ribbons, I wouldn't be worrying about the peeling paint...
Version 2.0 will replace all of your comments with your phone number and an increased salary demand.
Today's Sesame Street was brought to you by the number e.
Reviewer: "Where do you see yourself in 5 years time?"
Reviewee: "Your boss."
Reviewer: "Right, ok that will be all."
If you're smart, you'd say "still reporting directly to you...but you're the president of the company". That way, you shouw you're politically smart and not just ambitious.
SO YOU'RE GOING TO DIE: The Comic for Dealing with Death
I call bullshit on this. I work for and have worked for game companies. Producing AAA titles. For consoles and PC. Game companies are some of the best examples of what NOT to do in software development. Project management is non-existent, any kind of thought towards software architecture doesn't exist, rewriting every possible goddamn wheel they can is par for the course. Blizzard is the exception! Neverwinter Nights was a buggy piece of shit. All of the Bioware games have had significant crash problems in fact. Epic? WTF? Are you high? Unreal2 sucks. Not to mention the source code. Anyone who has bought the engine can tell you, its terrible. Not 3d Studio terrible, but not good. Blizzard is the only thing you got right there. They're big winners (for real).
Most game companies are concerned with getting shit out the door. If your entire company depends on 1 title being released every 2 or 3 years and selling like crazy you want to release. Plus after 2 or 3 years no one cares. Especially, since most games end up in some inane death march due to the aforementioned lack of project management or any sane person with a clue as to how software design should take place.
Note to all, if you want some beautiful examples of how a software project can totally be fucked up by lack of coders turned managers without any clue what their doing, look at the game industry.
How To Write Unmaintainable Code never gets old.
10) Åccented Letters: Use accented characters on variable names. E.g.
typedef struct { int i; } ínt;
where the second ínt's í is actually i-acute. With only a simple text editor, it's nearly impossible to distinguish the slant of the accent mark.
and:
15) Names From Other Languages: Use foreign language dictionaries as a source for variable names. For example, use the German punkt for point. Maintenance coders, without your firm grasp of German, will enjoy the multicultural experience of deciphering the meaning.
"If he thinks he can hide and run from the United States and our allies, he's sorely mistaken." Bush on bin Laden
I have seen something much like this. I was going through some directories of a previous employee whose code I was inheriting, and I came across a directory filled with SQL scripts. They were all named:
z.sqlzz.sql
zzz.sql
zzzz.sql
zzzzz.sql
...
all the way to zzzzzzzzzzzzzzzz.sql. I kid you not!
I believe in de-evolution. God made the world perfect, man fell, and its been going downhill ever since!