Skip to main content

For and Against and For Software Craftsmanship

Reading: For and Against and For Software Craftsmanship

The idea of software craftsmanship, as expressed in the Manifesto for Software Craftsmanship, is (in part) to encourage software developers to strive for excellence in their work in order to create productive partnerships with customers and to add value steadily for those customers.
The highly respected software developer and customer-focused consultant, Dan North, blogged in 2011 that “Software Craftsmanship risks putting the software at the centre rather than the benefit the software is supposed to deliver.” Let’s ignore (or try to ignore) the obvious contradiction between the critique of the concept and its actual expression, and examine an analogy Dan uses to illustrate his point.

He points out that in a craft such as, for instance, cathedral-building, the work is intrinsically beautiful in its own right. In contrast, using the same sort of stone as was used in the cathedral to build a bridge, the goal is to make the bridge sturdy and utilitarian, such that people don’t even notice it.

As I see it, both the cathedral and the bridge are equally beautiful. Each is designed to serve a particular purpose. One purpose of the cathedral is to inspire awe and wonder in those who see it. This is one of the ways in which it performs its function in the society. One purpose of the bridge is to be functional without distracting the user from his/her own business. This is one of the ways in which it performs its function in the society. These are different design goals, and yet both require the same degree of engineering skill and craftsmanship.

Joel Spolsky has also questioned the usefulness of the term “craftsmanship” as applied to software. In a piece dating from 2003, he writes “If writing code is not assembly-line style production, what is it? Some have proposed the label craftsmanship. That’s not quite right, either, because I don’t care what you say: that dialog box in Windows that asks you how you want your help file indexed does not in any way, shape, or form resemble what any normal English speaker would refer to as ‘craftsmanship.'”

He’s right. The average English speaker does associate some sort of subjective notion of “beauty” or “artistry” with the word “craftsmanship.” But average English speakers don’t know any more about what makes the utilitarian bridge “beautiful” to an engineer than they know what makes the Windows dialog box “beautiful” to a software developer. And they don’t need to know that. It isn’t part of their world. They’re getting what they need from the cathedral, the bridge, and the dialog box. That is, in fact, the reason those things are recognized as beautiful by makers. If the dialog box performs its function without interfering with the user’s workflow, it’s damned beautiful. It’s as beautiful as a cathedral.

Another highly-respected software expert, Liz Keogh, has also weighed in against the idea of software craftsmanship; or at least, against the way the idea has been expressed. She writes, “I dislike the wording of the manifesto’s points because I don’t think they differentiate between programmers who genuinely care about the value they deliver, programmers who care about the beauty of their code, and programmers who hold a mistaken belief in their own abilities. Any software developer–even the naive, straight-out-of-college engineer with no knowledge of design and little knowledge of incremental delivery–could sign up to that manifesto in the mistaken belief that they were doing the things it espouses.”

She’s right. Many individuals overestimate their own abilities. I disagree that this invalidates the attempt to express an aspirational goal…and it says right near the top of the manifesto: “As aspiring software craftsmen…” (emphasis mine). So, it isn’t a question of people believing they’re already software craftsmen. Therefore, although Liz is correct in saying some people overestimate their own abilities, that fact has nothing to do with the document in question.

Liz is also right that different statements in the manifesto address different topics: Both customer value and code quality are mentioned. One is a goal and the other is a means. Both should be mentioned.

And there’s a false dichotomy in Liz’s comment, I think. Why would a software craftsperson not care about both the value they deliver and the beauty of their code? Does one negate the other? Indeed, doesn’t attention to clean design help support value delivery? Badly-designed code is more likely to contain errors and more likely to be hard to maintain than well-designed code.

The manifesto, like most products of humans beings, is imperfect. If we were to wait for a thing to be perfect before finding it in any way useful, then we’d still be fleeing from sabre-toothed cats in the tall grass of the savannah. Actually, come to think of it, we wouldn’t. We’d be dead. Our ancestors would have eschewed any less-than-perfect means of escape. Having eschewed, they would have been chewed.

Why is it that critics of software craftsmanship seem to miss the point? I might offer three humble observations.

1. Snap judgment

The criticisms of the manifesto almost universally suggest the critic has not read the document carefully. It’s possible that some people read the title and skim the thing, and then react on a gut level to one or more words they assume carry some implication they disapprove of.

It seems to me “add value steadily [for] customers” doesn’t mean “elevate the software above customer value.” Similarly, “aspiring software craftsmen” doesn’t mean “I overestimate my own abilities.”

2. Inability to compartmentalize thinking

When we try to understand a complicated thing, it’s often useful to switch between big-picture and focused thinking. We want to keep the whole in mind without discarding our ability to comprehend its parts.

The big picture is that the purpose of software development is to provide value to the stakeholders of the software. I doubt anyone means to elevate the craft of software development above that purpose. To think about, talk about, and strive to excel in the craft of software development takes nothing away from the larger goal of providing value to stakeholders. Indeed, such activity is motivated by the desire to provide that value. I might suggest it would be difficult, if not impossible, to deliver value to customers without paying due attention to craftsmanship.

If we turn the critique around, we might ask: How does one propose to provide value to the stakeholders of software without understanding or applying good software development practices? How does one propose to develop an understanding of good software development practices, and sound habits to apply them, without making a conscious and mindful effort to do so? If the stonemasons and others involved in construction had ignored the skills of their respective crafts, how good would the cathedral be? The bridge?

3. Limited conception of beauty

If we define “beauty” to suggest a close alignment between the finished product and its design goals, then I suggest both the cathedral and the bridge are beautiful from the perspective of the engineers, architects, and craftsmen who contributed to their construction. The fact the cathedral catches the attention of passers-by while the bridge goes unnoticed as people cross it means nothing less than both structures have achieved their design goals. Their “users” appreciate the value both objects bring, even if they don’t grasp the nuances of craftsmanship that went into their construction. And without those nuances, the cathedral would be nothing more than “a big hut for people to meet in” and the bridge would be a disaster waiting to happen.


At LeadingAgile, we appreciate software craftsmanship. We understand it exists solely to enable the delivery of value to customers. We’re frankly a bit confused when we hear or read interpretations that miss that point. We also understand that without attention to excellence of execution, no one can deliver value to customers. Has the manifesto been signed by people who may not be well qualified to speak of craftsmanship? Maybe, but the document is more a commitment than a diploma, so I think it’s fine for anyone to sign it who is on board with the concept. When you sign it, you place yourself publicly on a lifelong journey of learning and self-improvement. I’m at a loss to see what’s wrong with that.

Next Capability Mapping with Ric Merrifield

Comments (7)

  1. Liz Keogh

    Hi Dave,

    I’ve been a long-term proponent of readable, maintainable software; of communities of practitioners; of building better relationships between developers, IT operations, business, and all manner of other stakeholders; and of delivering customer value. If you want to call that “craftsmanship” then I’m a fan of it; I just don’t find the name useful. If you do, that’s fine.

    My blog post was against the manifesto itself. I wrote my post 5 years ago and still hold the same views now.

    You talked about building software like a bridge that’s “a disaster waiting to happen”. Just because someone doesn’t sign the manifesto doesn’t mean they’re going to write poor-quality code, and signing the manifesto won’t prevent those disasters, especially since software development is not a solo activity. Signing the manifesto is neither necessary, nor sufficient.

    There are many other ways to sign up for a lifelong journey of learning and improvement, which may or may not involve software. I also respect people who prefer to make that commitment to themselves privately.

    You also asked, “How does one propose to provide value to the stakeholders of software without understanding or applying good software development practices?”

    This completely ignores all the other roles that help to deliver that value! What about the people who work to prioritize ideas, or write the content, or market the new product? What about those of us who help make organizations become the kind of places in which good software development is possible?

    I don’t believe you intend elitism in your statements here… but it does make it very easy to fall into that trap, and it creates tribal behaviours that are unhelpful for those of us trying to dissolve, not enhance, the barriers between development, the wider IT community and the rest of the world.

    I’ve seen the impact of those kind of behaviours first-hand. I believe the manifesto’s goals are limited, rather than aspirational; that – as Dan put it – the glamour is *still* overtaking the intent; and that its narrow focus renders it not merely pointless, but actively harmful.

    • Dave Nicolette

      Hi Liz,

      I appreciate your perspective, although I think you overreact on a couple of points. First, you write “Just because someone doesn’t sign the manifesto doesn’t mean they’re going to write poor-quality code, and signing the manifesto won’t prevent those disasters…” That’s certainly true. For some people, putting their name to a document that states their intention to learn and improve may be helpful.

      Elsewhere you write, “This completely ignores all the other roles that help to deliver that value!” My reply is: No, it doesn’t. Mentioning one detail doesn’t imply that all other context is ignored. This is an odd sort of response that I see surprisingly often, when anyone makes any statement about anything in any forum.

      “I believe the manifesto’s goals are limited, rather than aspirational…” Well, okay. :-)

      • Liz Keogh

        Dave, you didn’t mention it; you “turned the critque around” and questioned it.

        Even in the software space, this question has plenty of answers. I invite you to look at the “Chaos Grazing” (purple) pattern from Cynefin, as practiced by many, many start-ups I’ve encountered: .

        You might recognize the craftsmanship you espouse in the blue one, but it isn’t the only means by which software gets delivered. Sometimes what’s needed really is just a big hut that people can meet in, and that’s OK too.

  2. Brian Balke

    I appreciate this aspect of both the Agile Manifesto and your refinement, the Manifesto for Software Craftsmanship: they both attempt to address the problem of anomie that develops in people working in the Tower of Babel that is modern software development. Your appeal for craftsmanship, it seems to me, must lead to an evolution of idioms that are shared by a community. That in itself, however, creates private languages that exacerbate the underlying problem, a problem first described by Adam Smith when considering the problem of specialization of work in The Wealth of Nations: new technology makes redundant the specialized craftsman.

    Considering management as the most subtle of programming problems: It’s not until we recognize the difficult and importance of creating sustainable systems for generation and enhanced of knowledge that we will succeed in learning to manage software development, an activity that only generates and codifies knowledge.

    Competent software development departs only from understanding. Unfortunately, that specific understanding is the only source of security for the knowledge worker. It’s a Catch-22 situation, and one that can be solved only through management guarantees to employees. Places such as Google and Apple avoid this problem by throwing money at people; IBM and Microsoft have been forced to make the more difficult management choices that confront the rest of corporate America. I don’t know which part of the industry you serve, but appeals to professional pride may not be enough to solve the problem, especially when attempting to influence people that recognize the sociological realities that make their professional situation so unstable.

  3. Paul Kemner

    There’s also apparently a lack of understanding on what constitutes craftsmanship. *Some* craft tasks are prosaic and just need to be done in a basic, competent way (clicking that dialog box, or feeding boards into a planer), and some demand careful thought and execution (code that can survive future changes and be understood, designing & building a chair so it can survive considerable stresses and still look good.)

    And some of the Medieval cathedrals did come crashing down, just as disastrously as a bridge failing. Much of the beauty came from the mathematics of constructing a large open space that doesn’t collapse under its own weight.

  4. Terry Zenner

    What a load of self promoting crap. Comparing traditional craftsmsnship in which the mind and hands produce authentic and tangible priducts with software is pathetic.

    You are confusing workmanship with craftmanhip. This is all too common in the mind numbing field of software development. If you have a psychological need to be called a craftsman, take up stained glass design, cabinet making or another craft that will endure generations of use and admiration. The software you are working on today will have no value whatsoever 75 years from now.


Leave a comment

Your email address will not be published. Required fields are marked *