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

Hammer != Compiler

[viper21]

We can buy trashed houses and fix them up to our hearts content... will these new Software Craftsmen also be open source advocates?

It would be pretty hard to repair the shoddy 'windows' on our 'house' if they are all licensed by Microsoft.

-S

Another article by McBreen

[Target Drone]

For a little humor people should also check out his article on How to Crash and Burn your Java project

Also, it may be hard to believe but having worked with Pete on the project that was "Crashed and burned" I can testify to the fact that the article is in fact non-fiction.

Re:Another article by McBreen

[Fnkmaster]

Yup, you're pretty much on the money. If the goal is transparent scalability, maybe you should first focus on making a system that is efficient (i.e. you don't need twenty computers in a cluster to run it), and reliable (with EJBs there are often so many extra things to break that they end up being less reliable). There are better O/R mapping tools out there, some of which are even free (Castor). The last project I worked on basically ended up eliminating entity beans and using almost exclusively stateless session beans. At which point we realized we were pretty much using no features of the EJB container exception transactionality at function call boundaries. Not that this is so hard that you need all that complexity to address it - a much simpler framework could provide declarative transactionality.

Of course, we couldn't eliminate EJBs entirely, because our customers really wanted it to run with the Weblogic 6 licenses they had bought (woe befalls he who tries to explain that if you are going to use EJBs, you might as well use JBoss since it's a ton faster and generally more reliable than Weblogic, and pretty well supported through their online forum). But then again the customers wanted to know they could call Weblogic with a problem - of course, Weblogic would never really be able to help them anyway (I know, I've tried their "support").

Yup, basically I would never use EJBs in pretty much any project I can think of again, since they just don't solve enough problems to be worth the pain and hassle. What they DO provide, and the reason people use them, is an application "blueprint" for teams without a decent architect to solve their structural problems. It's just possibly the worst such model imaginable, and it's truly sad that this model has caught on. If you want a framework for a truly distributed, reliable, scalable framework, Jini and, say, JavaSpaces provided MUCH more interesting options, but had no corporate acceptance. If you had REAL problems that require a distributed framework, this was the way to go, since EJBs have absolutely no awareness of the location remoteness features they provide built in (resulting in a potential mess of RMI shit in all but very, very simple systems). Which, in short, is why everyone ends up scrapping entity beans.

Ugh. Thanks for reminding me why the enterprise software business sucks so much. :)

Software Engineering is different in Purpose

[etcshadow]

Contrary to what the author of this review is saying, I really do think that software engineering is different from software craftsmanship. Although you can take many of the things said about software engineering and come up with an application of them similar to an application you could come up with for software craftsmanship, but in practice you wouldn't. This is because the underlying philosophies are very different, and they exist for different purposes. The philosophies/purposes break down like this:

Software Engineering: make the development of software a controllable business process.

Software Craftsmanship: make the best software.

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. A subtle side effect of this is that it also tends to prevent any extremely great individual contribution from having a large impact. That is, the goal is to make all of your coders cogs in a machine. The business owners and managers would much rather have this setup because it makes it easier for them to sleep at night.

Re:Software Engineering is different in Purpose

[renehollan]

As with many things, the software "engineering" vs. craftmanship dichotomy is not completely black and white.

Whereas engineering is about reproducable, and measurable processes that can be constrained within certain bounds, craftmanship is about being able to build things that serve a purpose.

To some degree a craftsman will delve into a standard repetoire of tricks and techniques to get a job done, reflecting the "engineering" aspect of the job. However, what makes a craft interesting is that no two assignments are alike, and the job-specific problems, and how they are solved separate the master from the novice, not mere knowledge of a larger repetoire of canned solutions to known problems.

Because programming is such a young discipline (as opposed, say, to building buildings, bridges, or even airplanes), there is a log of original craftmanship involved in most projects. When a design pattern is found to be useful, it is catalogued, communicated, and often finds generic implementation in some piece of code, or higher-level programming language -- application-specific languages, or languages "tuned" to be particularly useful for certain applications reflect "software engineering": we've solved this problem, this is the general approach, and here are the parameters within which this solution works. A design pattern, implemented, becomes a "rough in" of a piece of code.

What this means, of course, is that the repeatable stuff becomes engineered, leaving only the "finish work" to be crafted. Leading edge programmers pushing the envelope of what the "finish work" is are thus craftspersons, and commensurate with the original work they do, notoriously unable to provide time, complexity, and labour estimates: when the job is done, they will know how long it will take.

This, of course is frustrating to traditional management teams. For software is not like a house. The interesting stuff, and the stuff that sells as the next "killer app" is precisely the stuff that no one has yet produced, reducing it to a low-margin commodity, instead of the "hot" program it is. And this stuff is not engineered -- it is crafted.

Software patents and copyrights ensure artificially high value for what would otherwise be commodity software, restricting its proliferation until it is ubiquitous, and commensurately high salaries for "assembly-line software engineers". Without them, the high-margin areas would be those of the leading edge, crafted code -- protected by copyright and patent for a short duration, perhaps, to encourage progression of the art, and recoupment of development efforts.

Interestingly, some 95% of all code is not engineereed according to a simple blueprint, but custom-crafted, Microsoft Office sales duely noted. Even if you can buy all the pipe and fittings you need, a plumber to cut things to proper lengths is handy. If all commodity software were free, there would be plenty of employment for software craftspersons (on this, I agree with RMS). Software engineers, in the guise of assembly-line coders, would be relegated to the ranks to apprentice, or "do it yourselfer". Perhaps when this happens, true software engineering, that is the polishing of a custom crafted design into a generic cookie-cutter component, understandable and consumable by the apprentice, will properly refer to the master software craftsperson.

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.

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

Look.

[Boss, Pointy Haired]

There is no magic bullet or even way of thinking that is overnight going to make IT projects run on time and on budget.

Software Engineering has a substantial creative component to it that is far more akin to music or art than to other forms of engineering.

And just like music or art;

* a few of us are REALLY GOOD

* some of can perform the programming equivalent of playing "Three Blind Mice" on the piano

* and some of us SUCK.

Trouble is, in the IT industry, as opposed to other creative industries, there is little salary difference between the three.

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

Re:What he says

[Shaleh]

my experience in corporate America is that the bit bangers APPEAR to be more productive but are actually less or even counter productive. If programmer A takes 2 hours to code a crap solution and 3 days to fix it versus the craftsman who take 2 days to do it once and do it right, programmer A looks good initially but becomes a liability.

A friend of mine is definately the tortoise, slow as it goes, programmer type. Some of the younger hackers mock him. But if you look at the total output he comes out on top because he spends far less time debugging. Managers need to understand that simple output is an invalid measure and look more at the whole process. This is especially valid in places that do a devel cycle followed by a cleanup cycle. The friend I referenced earlier often spends the cleanup phase of projects helping the bit bangers out because he has nothing else to do.

Re:What he says

[Anonymous Coward]

If coding is tedious and you don't like building your application in painstakingly slow fashion, then maybe you should find a craft which better addresses your passion, or at least try and be patient with yourself as you grow. Each project, in my humble belief, should allow you to grow as a craftsmen until you reach that nebulous peak of perfection.

As a programmer by day, I'd love to take my take my time and perfect my work, but we have these silly little things called budgets, deliverable dates, constantly changing requirements, and way too many incompetent coworkers.
Programming is not like building stuff in the real world. There are only so many 'features' people will ask for in a picnic table, but for a piece of software its virtually infinite. There is no perfection because no-one can agree on what perfection is for any significant application.

Re:Meta-Programming books suck

[CrazyLegs]

Patterns are way too overused for my tastes. They speak to structures and themes rather than methodology. As well, they are not too useful in framing up a users requirements. Rather, they present a design lingua franca for programmers. So, while they are interesting to think about, patterns (to me) are much more of a rear-window view of design.

Design Patterns suck

[alispguru]

(the subject is flamebait and overstated, but it did get you to read this, didn't it?)

According to Peter Norvig and Greg Sullivan, most of the patterns in the Gang of Four book are there to show users of common OO languages the canonical ways of getting around design flaws in those languages.

Norvig says 16 of 24 patterns either vanish completely or are significantly easier to implement in a dynamic OO language like CLOS or Dylan; Sullivan implements a tiny OO language in Scheme and uses it to implement all 24 patterns, with similar results.

Go read the papers before modding me down, huh?