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.

Conclusion

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.