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.
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.
Quite the contrary - there isn't a single personal attack in the review. The content of the book and its assertions are pretty much torn apart, but there isn't any slam directly on the author...
Stop by my site where I write about ERP systems & more
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).
you must be trolling. you only want good reviews? get over the "any press is good press" phobia.
and not "Advertisment."
What were you expecting?
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.
Come on, it's more of an art. What's better than constructing an elegantly written piece of code. Granted, most programs are closer to a "Cathy" comic strip than a Piccasso, yet there is something so nice about the occasionally beautifally crafted script.
Singleton has got to be the most over-used pattern ever. There are hardly any legitimate cases for a singleton, yet it's the first pattern anyone learns. They then go off and litter their code with the bloody things.
We took to calling our ERP software that we we're responsible for supporting and customizing "The house that love built." It had a long history of many owners and installed base in critical production environments. Despite the desire to burn it to the foundation to fix it, we were limited by time and money. We had plenty of ugly interfaces that put the toilet next to the refrigerator, load-bearing posters, and if we ran out of floorboard, we weren't above painting the dirt.
I sometimes wish we were working on an old house, as our house was flying down the street at the speed limit, and no one was willing to stop to make the required repairs.
How much can craftsman programmers learn when their walkthroughs are confined to the sample home (development environment)? They rarely go near a lived-in home (production environment) and may have never talked to an actual homeowner (customer) in their entire career.
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. All from the knowledge that there's exactly one instance? That's impressive
I dunno, that didn't look like a personal attack to me. Sure, one could interpret it that way, but think about it: all the reviewer has to go on is the material. If the material asserts that software engineering is X and then later on the material presents software engineering as z, theta, and epsilon, each of which is !X, then the only conclusion one can come to is that the material does not present a consistent description of software engineering and the author of the material either doesn't know, or changed his mind several times and didn't edit well.
Oh, go on, check out my job.
The basic notion of software engineering is to create a *process* which is so perfect that no personal weaknesses in your programmers can hurt the company.
This is a very dangerous notion, and I disagree with it.
Engineering is about creating technology. It's unfortunate that most "Software Engineers" are clueless doe-eyed grads or uneducated bureaucrats, but that is a symptom of the overall immaturity of the industry. It's unfortunate that the overall credibility and quality in the software industry is so poor that people impose soul-less processes to eliminate risk.
Look at engineering firms like the Skunk Works or early NASA, who produced tremendous technology in an almost absurd amount of time. With the cogs-in-a-wheel method, these organizations would still be making paper airplanes and the sound barrier would be a finger in the ear!
Even with RUP, Extreme this-and-that, CMM, whatever, nothing can replace individual talent in an engineering project, and absolutely nothing can completely remove the risk associated with these talented individuals.
Healthcare article at Kuro5hin
This may seem slightly off-topic, but bear with me, and the relevance will become clear...
My family owns a home-improvement business (I don't work there now, but did summers during college) and often deal with builders who work on the principle described by the author.
On more than a few occasions when I worked there, I would go to hang rain gutters (on new homes) and find all sorts of messes: Corners not square, roofing materials cut way too short or way too long, roof vent holes that have had shingles nailed over them, and even more idiotic and egregious mistakes than this--All of them perpetrated by either apprentices under supervision, journeymen or mastercrafstmen. Usually, it was the result of a project that was behind schedule and needing to cut corners to catch up.
My point? It doesn't matter what "Quality Assurance" system you have in place if you set unrealistic goals and/or hire the cheapest labor you can get your hands on.
Who did what now?
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.
This type of thing happens in the real world ALL THE TIME. Talk to anyone who has had a home built for them. Critical people or equipment doesn't show up on time, structure is far more fluid than people ever suspect, and what was presented to the customer via blueprints and models still may not be what they were expecting.
Engineering is knowing when to say good enough. A component performs as specified in the requirements. That is, if they say they need a hinge that will hold an aluminum door they don't build it out of titanium. For cranking out code, this is really an art. XP touches on this (and goes to far IMHO) about focusing on the task at hand rather than building large frameworks, object models, etc. There is a balance there, but for most construction these days the spec is 'good enough'.
Craftsmanship is taking the time to make sure every stud in the house is square. This is not an engineering requirement - the requirement is to support the wall. This is about polish and taking extra time to 'do things correctly'. It takes time, usually is not budgeted, and is a godsend to the folks having to maintain it down the road. These things also tend to live far beyond everyone's expectations. Think of some of the deep space probes landing on asteroids - craftsmanship. The mars lander comes to mind when you mentioned bolts.
Craftsmanship is also about using the right tool for the job. As I learned some basic carpentry skills, my grandfather would comment 'Any power tool used improperly can be a sander'. This applies to the real world as well as software. Let him that has not done an ugly hack throw the first stone - but duct tape and bailing wire are staples of engineering jokes because they are about getting the job done, but not in an elegant manner.
When I build stuff for others, solid engineering is enough. For my personal projects, I expect craftsmanship.
Course, I have not seen the book, so I may be way off track here...
+++ UGUCAUCGUAUUUCU
...are like $#@holes. Everyone has one, and they all stink. So I agree with this critique.
I'd like to add my two cents, so here it is:
Every year or so, some wingnut comes out with a "brand new paradigm" of software development, which is supposed to totally shake up all established practices and change the world overnight. And, it's all hogwash, but inexperienced programmers and the wannabes who take the six-month-special course in a back alley in NYC hoping to make it big in "Computers" all jump on the bandwagon and make life miserable for the rest of us. I've been programming in one language or another since 1991 (although I've been using computers since 1983 or 4); I started studying it formally in 1995, and I've been working full time as a programmer since 1998. And, in all that time I have never seen anything come out that does a better job than plain, old software engineering.
You know what I think?
I think that in this age of "bigger, better, faster, more" people who can't make a name for themselves by building/doing something USEFUL try instead to become "visionaries". So they pull some weird new way of programming out of their asses, serve it up to us like it's filet mignon, and sell books about how to change everything you're doing yet again. This constant change prevents companies from building stable software. How can you work all the bugs out of anything, when every five minutes you're changing all your processes? As if the huge amount of turnover, outsourcing, and downsizing doesn't make long-term software development hard enough.
The worst thing is, managers assigned to IT teams frequently don't know enough about software engineering to understand the difference between one paradigm and the next. So they end up running willy-nilly from one to another, changing boats midstream in a doomed, Frogger-like attempt to not get sunk in the next layoff. Any new book that catches the manager's eye mesmerizes him.
Heaven help the gullible manager who ends up with an aggressive little ivy-league grad that wants to make a name for himself. Then the manager's gonna be led by the nose. After all, what does a manager respect more than pedigree? It doesn't matter that the kid's balls haven't even dropped yet, that he has no experience on any real project, that the closest he's come to load balancing is two PCs in his dorm room, serving static web pages to one user who keeps hitting "refresh"...
GOD.
When, oh when, will people learn?
We've already figured out how to manage software projects. We've understood what works and what doesn't for at least a couple of decades. The field is fairly well researched, so there is plenty of material available about software engineering, and all you have to do is go look it up. There's NO NEED to keep trying to change the process.
Feh. Snort.
Farewell! It's been a fine buncha years!
If all programming tasks were as exciting as defending a small village from rapacious bandits then I'm sure you would have no trouble finding brilliant programmers. Unfortunately a lot of software is not very exciting. I find it unlikely that there is a single programmer out there that writes commission accounting systems for fun.
As a hobbyist you have the opportunity to pick and choose your projects. A working programmer often has to solve business problems that aren't unique or exciting.
_Design Patterns_ is not a methodology book. Say it with me, "Design Patterns is NOT a methodology book."
The point I was trying to make (and apparently unsuccessfully) was that the basic foundations of software engineering are quite different than those in the real world.
I know... I'm just going through the process right now and the real world seems as horked up as some of the ugly software projects I've worked on. Call me cynical, but I've got friends in differing areas of engineering - aerospace, mechanical, electrical, genetic - and all of them have nightmare stories of projects that were loosely defined, under funded, impossible deadlines, etc. I'm not saying software engineering sucks less or more - just that these same problems woefully apply to others fields as well.
God help me, I was right there saying amen until you said this does not happen in the real world. I could be exceptionally unlucky, however.... (grin)
+++ UGUCAUCGUAUUUCU
If I didn't love it, I could've sold my house (oddly enough given the slump, Silicon Valley house prices haven't dropped much), gone somewhere else, and lived off the equity for a couple of years til I found something else to do.
Even programs that look tedious on the outside may have challenging algorithms on the inside.
Ok, so you say we all know how to software engineer, but I've been studying the classica paradigms and none of them are truly "perfect" like you so claim.
Even ideas as old as the spiral model have proven to be ineffective at one level or another.
The only "software engineering" that seems to have been perfected with the is the fact that if you do the same damn program for 20 years you're bound to get better at it. NASA is the classical (and really only) example of CMU's Capability Maturity Model at work. But how much does less than a MB of flight control software change in 40 years? Yeah, they're good at what they do and can predict errors with frightening accuracy because they've been doing the same program over and over again longer than anyone else.
What we need is a paradigm that works for a unique problem the FIRST time around. Not the 30th. Maybe your "old school" software engineering works in some "old school" industry you work in, but I think nearly every software engineering expert would agree that you're pulling this information out of your ass.