Software Craftsmanship in Context

There’s been some debate about a term that has become popular in the past couple of years: software craftsmanship. The basic idea is that as software professionals we ought to pay attention to the quality of our work. After all, where would we be otherwise?

That may sound like a harmless enough concept, but you might be surprised at the visceral reaction some people have to the term. What is it, exactly, that they dislike about it?

I’ve encountered two objections; more accurately, two broad categories of objections:

• as professionals, we ought to focus on delivering business value to our customers rather than on the technical details of our work; and
• the activity broadly known as “software development” isn’t really a craft, so the term software craftsmanship doesn’t fit.

I think these are valid concerns. I also think we need to be able to talk about our work without having to preface every remark with a paragraph-long disclaimer defending each individual word we choose to utter or write. So, let’s find a place somewhere in the middle where we can meet.

Should we focus on value or technical skill?

One broad area of concern is that software professionals need to keep in mind the value of their work. In this context, we mean value in the Lean sense: Value as defined by our customer, as opposed to a looser sense in which anything remotely useful may be regarded as “valuable,” if you squint just right. In other words, value is that for which the customer is willing to pay.

For example, most competent software developers understand the importance of testing in their work. However, a customer will not purchase a software product based its test coverage. That isn’t the “thing” they’re paying for. As developers we value testing, but that doesn’t make it part of customer-defined value.

The same goes for concerns like security, regulatory compliance, accessibility, auditability, and usability. A software product that lacks those things is, simply, unfinished. (Granted, there are some products for which one or more of those factors is key to its ability to meet its market need; but let’s not go on a tangent just now. Maybe later.)

Of course, customers expect our products to work properly and to be tolerant of common errors. That’s a baseline expectation, and not a value proposition.

This is the crux of one of the objections to the term, software craftsmanship. There is fear that by focusing on the technical details of our work, we will lose focus on our customers’ needs.

Superficially, that sounds like a valid issue, but questionable unstated assumptions are rife in the objection itself.

By the time a software development team receives its marching orders (yes, I know you don’t like that; bear with me a minute), all decisions about the potential customer value of the product have already been made. The task of the development team is to realize the product. That calls for a focus on technical exellence. Such a focus, applied in the right context and at the right time, does not interfere with or degrade the value delivered to the customer. Indeed, the software product itself is the primary, and in many cases the only vehicle for delivery of that value. It has to be built well.

Now, getting back to that offensive statement about marching orders…development teams like to consider themselves part of the value stream, and they are part of it. It just isn’t their role to assess the market, determine customer needs, allocate funds, or prioritize the work. It’s best that they have a clear understanding of the value they are delivering, but their day-to-day and minute-to-minute focus has to be on building the thing right, with trust that their colleagues in other parts of the value stream have ensured we are all building the right thing.

This is different in very, very, very, very small operations, of course. The majority of software developers are buried deep in the bowels of large corporate IT departments. They don’t have visibility into what real customers need. They never see a real customer. If they move into a position in the organization that gives them access to real customers, they will have moved away from hands-on software development. So, it’s proper for them to focus on technical excellence while they’re in a technical role.

So, is it a craft or isn’t it?

Yes, and yes; it is and it isn’t.

As a relatively new activity for humans (still well under a century old), software development hasn’t been around long enough for people to feel as if they really understand what it’s about. At the same time they’re struggling to understand software development, it changes under their feet; it’s still an emergent discipline. Most people depend on metaphors to help them get a handle on ideas that aren’t obvious to them. Software development is variously described as engineering, construction, manufacturing, science, art, human collaboration, and craft. Which is it, then?

Is software development a form of engineering?

In some ways, yes. Certain things have been learned over the years and have been codified as software design principles in one way or another. It’s sensible for us to apply those principles, rather than repeat all the mistakes of previous generations of developers. So yes, there is a certain degree of “engineering rigor” involved in professional-level software development.

You’ve heard of some of these principles. They are things like separation of concerns, referential transparency, and interface segregation. They usually come packaged in some pithy acronym that’s easy to remember, like GRASP or SOLID.

Just having some principles defined isn’t sufficient to make software development a true engineering discipline. It’s only a metaphor. After all, no one has to earn a Professional Engineer credential to get a job writing software.

Is software development like construction?

In some ways, yes. Most business applications run under the control of some sort of framework or container. At the very least, the code depends on an operating system that provides certain core functions such as arithmetic, and provides access to supporting functions such as input/output. Many contemporary applications live under multiple layers of other software, like Matryushka dolls: An operating system runs a server that hosts a container that manages an application that is based on a framework that implements a reference architecture.

On top of all that, business solutions often comprise multiple applications that live on disparate platforms. The overall solution has an architecture, a concept and term borrowed from the construction industry. There’s “architecture” to the way messages flow between components, the way data are structured, the way exceptions are handled, the way database integrity is maintained. So yes, there are some valid analogies with construction work.

But it’s only an analogy. You can deliver a “vertical slice” of functionality for an incomplete software product, and your customers can use it. You can’t deliver just the second bedroom of a house, all by itself, and expect it to be habitable. So, it isn’t exactly like construction.

Is software development like manufacturing?

In some ways, yes. The main difference between software development and manufacturing is the fact software isn’t physical. That has several implications for how it is built and delivered:

• We don’t produce each copy of a software product from raw material. We just build the first one and then copy it as needed.
• It’s feasible to deliver part of a software product and get feedback from customers about how to refine it. Much harder to do with physical products.

Aside from those differences, there are many similarities between the activity of building software and the activity of running an assembly line. Even if we are not reproducing the same widget over and over again, we are following a consistent set of steps to build each increment of a software solution. If that weren’t the case, it wouldn’t be possible to automate a software delivery pipeline. So yes, there are some valid analogies with manufacturing.

Is software development a science?

In some ways, yes. The whole field emerged from scientific research. Scientific aspects of computer science include formal logic (a field of mathematics), electronics, physics, chemistry, neuroscience, and more. Methods of building software were first elaborated by people working in applied sciences. To this day, university degree programs connected with software tend to be either (a) computer science or (b) management information systems. Only recently have educational institutions addressed the activity of software development as a discrete discipline. So, software development has deep roots in the sciences.

Some domains in which software is written are more “scientific” than business application development. Mathematical and statistical applications, artificial intelligence, and other fields call for software to be developed that directly implements scientific principles and models. Developers working in those domains must have a strong understanding of science.

And yet, for the most part, software development out in the world isn’t exactly “science.” Clearly, most of the existing legacy code currently in use doesn’t look as if it was designed by anyone with a scientific mind. And most of the run-of-the-mill software development and support work available for practitioners doesn’t require much “science.” Most of it involves making repetitive, routine modifications to the same code base over and over again.

So yes, there are some valid analogies with science, but the activity of building software isn’t exactly applied science. It’s only a metaphor.

Is software development an art?

In some ways, yes. The design and development of software can feel very much like any other creative activity, and one can experience the same emotional responses as one does when writing a piece of music or poetry. You watch your creation emerge in all its elegance, grace, and beauty…and its faults. Any decent Japanese flower-arranger can explain the role of small imperfections in creating art that is transient in nature, like flower arrangements or software. Practitioners often use words associated with art to describe pieces of software they appreciate.

Some people say this is nonsense. Software can’t be beautiful or elegant, in the same way as a cathedral can be. Such people, perhaps, lack passion for their chosen profession. If they had it, they would know software absolutely can be as beautiful as a cathedral (even if software from the bazaar is more popular).

Possibly the most practical parallel with the arts is the value of mindful practice for building software development expertise. Just as a musician must practice the basics every day (scales, embouchure-building exercises, finger-dexterity exercises, etc.), a software developer benefits from regular participation in code dojos and other hands-on learning events, and from regular practice on “side projects” where it’s safe to make mistakes, and you can learn without impacting a real project schedule.

So yes, there are some valid parallels with art, but software development isn’t exactly art. It’s only a metaphor.

Is software development a human activity rather than a technical one?

In some ways, yes. Some people characterize software development as a collaborative, human activity because in their experience the best outcomes have been achieved by “gelled teams” working in harmony with key business stakeholders. It’s certainly possible to write very good software on your own, too. But when you’re in a group setting and working as part of a team, there are definitely communication skills and human interaction skills (giving and receiving feedback, resolving conflicts, etc.) that can make or break a project.

In my view this is a valid metaphor, within limits. In many areas of human endeavor, it’s important to be able to work with others. And in many areas, the ideas results produced by a collaborative group outshine the results any one of the team members could have produced alone. And yet, software development isn’t exactly this, or uniquely this. It’s only a metaphor.

Is software development a craft?

Finally, the craftsmanship thing.

In some ways, it’s a craft, yes. And by now, you can probably guess where I’m going with it.

Wooden furniture can be churned out on an automated assembly line. Many people will be happy to buy it in stores like Ikea and Target. The best wooden furniture is created by craftspeople. They carefully select each piece of wood, and work in harmony with the nature of the piece to shape it into the form it “wants” to achieve. They use rigs that they build themselves to guide the assembly so that each chair in a set will be mostly the same. And yet, when a piece doesn’t fit just right, they can adapt. They shave off a bit here, sand a bit there. They go to some trouble to minimize the amount of glue they use, and they avoid screws if they possibly can. They make each piece as perfect as possible. It’s the pursuit of perfection that marks them as craftspeople as opposed to laborers. And it’s the pursuit of perfection, not the achievement of it, that matters.

When I’m working with a team of developers, it’s always a pleasure when they adopt the attitude of craftspeople. Each team member pursues perfection in every task, whether it’s adding a block of declarations to a configuration file, refactoring a unit test, or designing a new feature. The end result is so much better than when the work is done carelessly by people who aren’t fully engaged with their occupation.

When I say “end result” I’m thinking both of the value delivered to the customer and to the beauty of the solution as perceived by its creators and others who have the professional background to appreciate what they’re looking at. Both are important.

So yes, there are valid parallels with craftsmanship. All of them are positive; none detracts from customer-defined value. But still, it’s only a metaphor.

Software development is software development

In my experience (40 years, FWIW), there are times when the work of building software resembles one or more of the metaphors presented above. But it isn’t exactly any one of them, or all of them together. It’s a unique activity.

So, is software craftsmanship a useful metaphor? I think it’s as good as any. I’d like it if people whose professional work may be described as “applied logic” would cease and desist from halting as soon as they see or hear a word they think they disagree with, and proceed to find out what the writer or speaker is really talking about before they criticize. Asking too much? Maybe.