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

David Turner
Jul 1
4 min read

Updated: Aug 25

Why software engineering and art keep solving the same problems

Many leadership teams that commission a software project assume they are buying a technical outcome. They aren't; they're 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 until it's fixed. 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 fundamental problem - intention meeting an unforgiving medium - is not a new one. 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 weren't aesthetic choices, as much as being grounded in engineering constraints. What we now call microservices architecture - building software as isolated, independently deployable units with clean interfaces between them - was an unavoidable necessity in 1508. Scale requires decomposition. Decomposition requires discipline about where one thing ends and another begins. The problems and constraints have never really changed; only the vocabulary and technicalities have.

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. 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

It's maybe better 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 type of solutions. The Renaissance atelier solved the scale problem long 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. That Methodology is a functional reality.

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 of greater value 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, same epistemology.

What software leadership discussions miss

Methodology is a risk decision rather than anything cultural. 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.

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 become ever 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, the spectre of game theory looming over their shoulder. 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.

You can reach him at: enquiries@dkoi.design