Art, Code, and the Unforgiving Medium: Why software engineering and art keep solving the same problems

David Turner
3 days ago
4 min read

Why software engineering and art keep solving the same problems

Most leadership teams that commission a software project assume they are buying a technical outcome. They are not. They are commissioning a translation. The engineers are attempting to project a complex, half-formed internal model of how something should work into a medium that tolerates no ambiguity. Code either runs or it does not. A misplaced semicolon fails silently for months. But these aren't necessarily new problems. This train of thought led me to ask why software engineering and art keep solving the same problems.

That structural problem - intention meeting an unforgiving medium - is not new. Michelangelo divided the Sistine Chapel ceiling into discrete sections of fresh plaster, each one called a giornata, worked to completion before the plaster dried and made revision impossible. Each section had to function independently while remaining part of a larger whole. The boundaries were not aesthetic choices. They were engineering constraints. What we now call microservices architecture - building software as isolated, independently deployable units with clean interfaces between them - was a structural necessity in 1508. Scale requires decomposition. Decomposition requires discipline about where one thing ends and another begins. The vocabulary changed, but the problem did not.

The ghost of every decision that was made and then changed lives in the medium. X-ray analysis of Old Masters reveals pentimenti: original underdrawings, earlier compositions, figures moved, hands repositioned. Not failures, but evidence of thinking under uncertainty. Silicon Valley tells engineers to 'move fast and break things'. The Lean Startup told us to rapidly experiment, iterate and test our hypothesis for viability. Pentimenti are strewn throughout the software and products generated by these approaches.

The Cost of What You Cannot See

The more useful frame is to treat art and software as the same problem: organising human creativity at scale, under constraint, with imperfect information. Both fields independently arrived at the same structural solutions. The Renaissance atelier solved the scale problem before software existed as a concept.

Rubens designed the major works, established the compositional framework, and reviewed his apprentices' execution. Van Dyck eventually forked the codebase, established his own studio, and surpassed Rubens in the field he chose. Git, the version control system underpinning most of the world's software, formalises exactly this: a master repository, branches, independent lines of work, the ability to merge or to diverge permanently.

Extending this concept we may choose to look at open source software and collaboration as an invention of the modern era. But conceptually is it really so different to Louis XIV's 'Manufacture Royale des Meubles de la Couronne' in 17th-century Paris? Where France's best clockmakers, goldsmiths, Marquetarians and Sculptors were consolidated into one centralised location, asserting the country's cultural and economic supremacy over luxury goods.

Critics of Waterfall development tend to misread it. Sequential, phase-gated methodology is impractical for iterative products. For high-stakes, irreversible work, it is the only rational approach. Bronze casting cannot be revised after the metal is poured. The maquette, the armature, the pour: each phase is sequential because it must be. Automotive and Aerospace developments still use formal sequential methods for exactly this reason - you don't produce the car before the factory is built and the suppliers are tooled. Methodology is not a philosophical position. It is a function of what happens when you get it wrong.

The Agile movement that displaced Waterfall in the mainstream drew, mostly without acknowledgement, on principles that Impressionism had worked through a century earlier. The Impressionists rejected long, carefully planned academic canvases requiring exact compositional agreement in advance. They worked quickly, outside, plein air, accepting that immediate observation was worth more than academic finish. The Agile Manifesto of 2001 said almost the same thing: working code over comprehensive documentation, responding to change over following a plan. It named its planning sessions sprints, its retrospective meetings critiques, its incremental outputs iterations. Different vocabulary, the same epistemology.

What software leadership discussions miss

Methodology is a risk decision, not a cultural one. Agile suits products where requirements will change and failure is recoverable. Sequential methods suit products where failure is catastrophic. Using the wrong one is a judgement failure, not a process one.

Generative tools that write code from natural language are not just simplistically replacing engineers. They are also doing what every preceding layer of abstraction did: raising the floor of what non-specialists can produce and raising the ceiling of what specialists can build. The engineer's work has moved upstream, into specification and selection. The judgement required has not diminished. It has become more consequential.

Photography did not kill painting. It took painters forty years to work out what it had liberated them to do. The current anxiety about generative AI in software will follow the same arc. The question for anyone leading a software organisation is whether they are managing that transition or waiting to discover what it does to them.

Look to the abstract for answers

What I regularly see in the post-AI world are organisations jumping straight into hyperbole and complexity in an attempt not to be the last to adopt. And that usually results in messy implementation with little of the promised efficiency. Looking backward however is sometimes the best way to look forward, reinforcing the growing demand for abstract thinkers versed in the liberal arts. As the engineer's work moves upstream, the abstraction must follow.

David Turner is the founder of Kói, an independent strategic consultancy advising investors, founders, and boards on technology.