Stories about Software


Software Craftsmanship and the Art of Software


I’m a member of the LinkedIn group “Software Craftsmanship.” I’m not an active member, but I do like perusing the discussion topics. Recently, I read through this discussion on whether software is more of an “art” or a “craft.” This set me to musing a bit, so I thought I would post about it here.

Is Software a Craft?

A lot of discussion in the group seemed to involve meta-discussion about semantics. “What is a craft?” “What is art?” While this may seem like an academic exercise in splitting hairs, I feel that metaphors for process, software design, and pretty much everything that you might want to do are quite important–so much so that I made an earlier blog post about metaphors for software design in which I discussed this subject at length.

On the idea of whether or not software design and development is a craft, I think there are two operating definitions that potentially cloud the issue. One seems to be the dictionary definition that one might expect, where “craft” is something along the lines of a trade or some occupation that requires skill at something. Using this definition, software design is trivially a craft. There’s not a lot of room for argument there. I think the notion of software as a craft becomes more interesting in the context in which it’s adopted by the Software Craftsmanship movement–the idea of medieval craftsmanship in which there was some notion of apprenticeship being required before the aspiring tradesman could venture out into the world on his own. Perhaps naming the movement “Software Guildsmanship” would be more clear, if a little weird.

Software Guilds

At any rate, the guild metaphor is very good for expressing the feeling that there ought to be some standard met by anyone who wishes to develop software. At first blush, we might think that an undergraduate degree in Computer Science is the standard, but there are still plenty of self-taught programmers and people who attend trade school or else somehow transition into software development. And, furthermore, a computer science degree often gives more of a theoretical background as opposed to teaching would-be programmers the ropes of actual software development. In some very real sense, the CS degree is akin to taking courses in E&M physics to become an electrician. When you get done, you can give an excellent treatise on magnetic flux, but you may have no idea whether it’s really necessary to use conduit when connecting a switch to a junction box.

So, at present, there really is no modern-guild equivalent for software development. They do exist in other professions, though. The aforementioned electricians, lawyers, doctors, and certain types of engineers all belong to the modern equivalent of a guild, whether it’s a union with its political clout or some kind of licensing body (generally the functional equivalent of a union, particularly in the case of lawyers). The principles persist–some required standard for admittance (medical board exams), some notion of standardized pricing of services (union labor), repercussions for not cooperating with the explicit or implicit bylaws of the group (being “disbarred”), etc. The question is whether or not this should apply to software development, and I think that most members of the Software Craftsmanship school of thinking believe that it should.

Me, I’m not so sure. I think the intentions are sound, but the ramifications are potentially odd. Anyone who has looked at a particularly poorly designed piece of software probably, in that moment, would love some standardization of what is acceptable and to have the author of the offending code stripped of some kind of software development credentials. But that sort of overlooks all of the modes in which software is developed.

Lawyers, doctors, electricians, etc. are all sanctioned–“guilded,” if you will–because they provide some kind of external service — they act as agents for individuals or organizations. Software development has a wider range of use. Often we write software and sell it as a product, but sometimes we write software for fun, for friends, as a quick and dirty way to automate something, for posterity (FOSS), or internally for an organization who is both “purchaser” and “vendor” in one swoop. Contrast this with the guilded positions that I’ve been mentioning. People don’t practice law at home to make reading spreadsheets easier. People don’t practice medicine for fun. And some of these guilders could do what they do for free or internally for a company, but even if they did, they would act as an agent for someone who can be legitimately harmed by malpractice. If a pro-bono lawyer messes up, his client can still land in jail. If an incompetent electrician wires up his brother’s apartment, the apartment building can burn down.

With software, it’s a lot murkier. There are many scenarios in which software cannot have any negative ramifications for anyone involved. There is no implied responsibility simply because someone has created some piece of software, whereas there is implied responsibility in the guilded professions.

So Is the Metaphor Valid?

All that said, I think the idea of Software Craftsmanship is a valid one. But I think it’s important to remember that this is an imperfect metaphor. I like the idea of an opt-in software guild (i.e. potentially the Software Craftsmanship movement) in which members agree to practice due diligence with regard to producing good quality software. I even like the idea of apprenticeship, and I think that members of the movement ought to take on ‘apprentices’ (in a strictly voluntary interaction). This group of people ought to be software professionals and aspiring software professionals with the common goal of standardizing good practices and raising the bar of software design in general. But I think a slightly different metaphor is in order. After all, what I’m describing is less like a guild and more like a professional association.

Is Software Development an Art?

To this question, I have to give an opinion of a definite “no.” People like to have their work appreciated. If you spend a long enough time pouring your heart and soul into something, you will want to view it in an artistic context because you’ll want others to appreciate what you’ve done and see beauty in your work. But most forms of art, in the commonly accepted sense, are created for pure aesthetic value. Your software is only art if you never compile it, opting instead to print out the source code, frame it, and hang it over your mantle.

Make no mistake–at its core, software is a tool and a means to an end. You may be particularly efficient in creating these tools, but that doesn’t mean that you’re creating art. You’re automating processes and doing a good job of it. But nobody buys software for aesthetics. The only exception I can think of is software whose purpose is to look pretty or aesthetically appealing, such as video games or fractals. But the art there is in the rendering and not the software plumbing.

To refer to software development as an art, in my opinion, undercuts the value of the activity by implying that the goal is aesthetics rather than utility. We’re not selling people software because they want to own something that has the loosest component coupling they’ve ever seen or because it has no global state–we’re selling people software because they want to do their taxes, check their email, or look for reruns of sitcoms on the internet.

Software development is an art only inasmuch as everything is an art. If I hear developers talking about being good at their art, this to me is akin to mechanics talking about the ‘art’ of fixing cars or engineers talking about the ‘art’ of building planes. It’s only art in the vernacular sense of “This person is so much better at this activity than other people that I’m going to use the term ‘art’ to convey my appreciation.” I would argue that there is a certain danger in taking it any further than that. Specifically, the software designer who believes that his work is art is likely to lose sight of the fact that, without a need, there is no use for his work, and the aesthetics of filling that need do not trump the actual filling of the need. Nestcape might have been destined to be the most beautifully crafted piece of software in the history of mankind, but Internet Explorer still commands the market because its developers were interested in making money, not selling tickets to the grand unveiling.