Software Development is a Craft

Every once in a while, someone gets the bright idea that the job of a software developer can be eliminated through automation.

The fundamental problem with this idea is that software developers are already continuously automating the repetitive tasks within their jobs through the creation of new and better tools, so that the tasks remaining to the developer generally involve a significant degree of creativity and craftsmanship.

A closely related fallacy is that the element of craft can be eliminated through the creation of “software factories,” by applying principles of industrialized mass production to the job of software development.

But the notion of a software factory implies that there exists some means of specifying the intended software design that is somehow easier or better than producing the software code itself; again, though, once we acknowledge that the most repetitive coding tasks have already been automated, then the coding that remains is generally the best available means of documenting the detailed design of the software being produced; alternatives are either less complete and/or more difficult to evaluate.

The other problem with the idea of a software factory is the implicit notion that a product that exactly meets specifications is better than a product that exceeds expectations. In manufacturing, of course, we accept this as a given – if I order a widget from Amazon, I want the same widget that others have already purchased and reviewed, not a unique item that has been “improved” by the work of a craftsman in the factory; in the case of software, though, we are never producing exactly the same thing more than once, so the industrial values of standardization and consistency do not apply. Instead, what we find is that a craftsman can often add value to the finished software by producing something better than the minimum needed to satisfy the starting expectations: something more useful to the customer, and/or something easier and cheaper to maintain and enhance in the future.


Technology alone is not enough. It’s technology married with the liberal arts, married with the humanities, that yields the results that makes our hearts sing.


Artful making differs from what we call industrial making. The principles of industrial making are so embedded in business thinking that they’re transparent and we don’t notice them. But, as we shall see, industrial methods can distort reality and smother innovation. Artful and industrial making are distinct approaches and each must be applied in the appropriate conditions.


I have to program because of the aesthetics of it. I love to see the way it fits together and sort of sings to you.


In 1983, when he [Ken Thompson] and [Dennis] Richie won the Turing award, which has been called the Nobel prize of computer science, Thompson explained, “I am a programmer. On my 1040 form, that is what I put down as my occupation.” He has called programming an addiction of sorts, and it was in the Berkeley computer center that he got hooked. Sitting in the Bell Labs offices years later, he described the appeal as having all the craftsman’s satisfactions of making things, without the cost and trouble of procuring the materials. “It’s like building something where you don’t have to order the cement,” Thompson said. “You create a world of your own, your own environment, and you never leave this room.”


Another myth is the widespread belief that some technologically advanced tool or method will provide a magic answer to the software crisis. This is not only wrong, but it is dangerous.


Over the years, executives have backed their desire to eliminate programmers with staggering funds. Dozens of simplistic schemes have been heaped with money and praise on the promise — as yet not kept — of going directly from a sales proposal to a working data-processing system. Their touching faith in the magic of technology should serve as inspiration to those of us who daily bend our backs to the programmer’s burden. Perhaps their wishes — though they can surely never be fulfilled — should give us pause — make us lift our noses from the coding pad or the terminal — and consider this human activity of ours from a human point of view.

Next: Documentation Is Not an End Unto Itself