The Internet spaces I tend to inhabit have more polarisation than at many other recent times, and little explication of the worldviews that lead to different premises for discussion, that in turn lead to the polarisation and disagreement. Taking a step back to analyse the discussions, I think we see a debate that’s been raging for longer than I’ve been alive and that has no chance of reconciliation.
Is the program code that someone creates an artistic expression, or a tool that gets the job done? The useful answer is “both”, the pragmatic answer is “it depends on the context”, but the belief is often one or the other, or a large amount of one and a small amount of the other, and from there stem the arguments.
Code as art
When someone creates a program, they combine their technical skill with their humanitarian understanding and their aesthetic sensibilities to make something that has meaning to society and affects people in some way. They craft a design that expresses their current understanding of a situation, including their understanding of how that situation might evolve into future situations. Software serves two purposes: the use to which it’s put, and a demonstration of the skill of its creator.
Code as tool
When someone creates a program, they combine their technical skill with their humanitarian understanding and their aesthetic sensibilities to make something that has value to society and that people can apply in some way. They craft a design that solves a problem as they currently understand it, including their understanding of how that problem might evolve into future problems. Software serves two purposes: the use to which it’s put, and the adaptability toward future applications.
The half-century of discord
If you start from either of those places, people who start from the other place look like they don’t understand what software truly is.
To the code-artist, the act of programming is a creative effort that’s deeply personal and extractive, as there’s a part of themselves that goes into every interface, every abstraction, every carefully-considered parameter. “Technical debt” is a swear word because it means deliberately making unaesthetic choices. “Legacy code” is a swear word because some other, inferior artist created that, and the code-artist can do a better job.
Efficiency tools are swear words because they remove the creativity and expressivity from the craft, automating choices that by rights should be made by ingenious humans or—and this may be worse—allowing mass-production of art by duplicating a single work into multiple contexts, when the correct way is to hand-craft the bespoke design that’s most appropriate for each context. Of course, which specific tools are verboten depends on which tools are new at the time of the debate. Douglas Adams had it mostly right in The Salmon of Doubt:
- Anything that is in the world when you’re born is normal and ordinary and is just a natural part of the way the world works.
- Anything that’s invented between when you’re fifteen and thirty-five is new and exciting and revolutionary and you can probably get a career in it.
- Anything invented after you’re thirty-five is against the natural order of things.
So code-artists of a certain age in the 1960s might have thought that compilers and linkers are preternatural, when a true artist hand-selects the accumulators to use for each variable to make their code more efficient, and assembles functions into libraries to optimally load them in when they’re needed. People of a certain age in the 1980s might have thought that copying BASIC listings from Sinclair User is preternatural, because that’s just uncreative plagiarism and the copyist can never truly understand what’s going on. Take this latter argument out of its time and apply it again to getting code from comp.lang.c on Usenet, from answers on Stack Overflow, or from generative AI—and have about as much success with it as earlier arguments against the printing press or portrait photography.
To the code-toolsmith, the act of programming is a production process that’s performed to achieve some aim, so the principle is to move from “working towards the aim” to “having achieved the aim” as quickly as possible so that you can achieve some other aim. “Technical debt” is an acceptable decision that optimises for being done. “Legacy code” is delightful because it’s already achieving its aims.
Efficiency tools are wonderful because they remove uncertainty, decision-making, and individual effort from the task, by enabling mass adoption of known solutions to general problems. Why choose which accumulator to use for each variable when you can automate that, and think about the problem you’re solving? Why commission an oil painter, when you can press a button and have a visual record of the person stood in front of you? Why write potentially incorrect code when you can copy it out of Sinclair User or from an answer in Stack Overflow?
Code as both
[In drafting this post I adopted the portmanteau “tort” here—part tool, part art—which also works in suggesting that code can be a harm a person inflicts on another person.]
In any given situation, we see that code has both artistic and pragmatic qualities. Even in the extreme case of “program as art”, such as a demo scene demo, the code needs to work in that it needs to perform the functions that support drawing the demo’s graphics and playing its music correctly. Going to the further artistic extreme of example code in a tutorial or article—where the code is an aesthetic component in a creative work that has the sole goal of communicating a message from its creator to its viewers—it still needs to work in that the viewer needs to understand the message conveyed in the code and how to apply that meaning to their own situations: they don’t merely appreciate the code, they learn from it. Computers and Typesetting, Volume B by Donald Knuth isn’t just a book people can read, it’s a working digital typesetter, and it would fail as a book if it didn’t work.
In the other extreme, the archetypal “program as tool”, such as a line-of-business application written by an employee programmer, the code needs to convey in that it needs to demonstrate what the programmer’s understanding of the line of business is, and how they reified that understanding in software, so that they and others can come back to it and modify it when they discover that the understanding was wrong, or that the line of business has changed. They don’t merely use the code, they appreciate it. TeX by Donald Knuth isn’t just a working digital typesetter, it’s a book people can read, and it would fail as a digital typesetter if people couldn’t read it.
A synthetic understanding
We therefore need to create a common paradigm for understanding software quality that includes both the artistic and the pragmatic; both the external qualities of what it does, and the internal qualities of how it does it. When we don’t have that, we have people talking past each other when it comes to making the software: new tools are either diabolical interference in the creative art, or the best thing ever. But more than that: when we don’t have a synthetic basis for understanding software, we can’t work together to achieve software with either quality attribute. We split into “the business” who just want the problems solved and don’t see the value in the expressive nature of software, and “the technical people” who understand the craft of making and don’t see the benefit in doing a lesser job, faster. In theory, this is the point of the “engineering” idea in “software engineering”; to understand the science and art of software and apply both to improve systems.
This isn’t a new idea. Just as the arguments over copying a BASIC listing from a magazine have been raging for decades, so the “intersection of technology and the liberal arts” has been understood and re-understood, told and re-told, for just as long. It’s no coincidence that Computers and Typesetting, Volume B and TeX are actually the same work. I tell this story again today because it’s relevant today, to avoid creating two different camps of software creators who don’t understand each other.
