Cruft, Not Patina

Thirty-two years ago, Stewart Brand published a book called How Buildings Learn. Its thesis is simple and uncomfortable: a well-designed building isn’t one that stays identical to itself, but one that knows how to be modified, inhabited, patched, reinterpreted over time. Brand photographs the same buildings decades apart and shows the alterations that tell their story. A staircase added to one side. A wall knocked down to merge two offices. A roof rebuilt after a fire. A façade painted three times and then left to flake. Architectural quality, Brand argues, isn’t measured at the ribbon-cutting but in how the object holds up under stratified human use. The word he uses is learning: buildings learn, in the sense that their physical fabric accumulates information over the years, and at some point the accumulated information itself becomes part of the object’s value.

Software doesn’t learn, in that sense. Software accumulates comments that apologize.

The archaeology of old code

Anyone who has worked on a codebase older than ten years recognizes a particular kind of comment. // HACK: remove when we migrate to API v2. // TODO: figure out why this works. // DO NOT TOUCH: broke production three times. They are signed by people who no longer work there, addressed to future readers who will never quite get around to resolving them. Are they patina? No — they are scar tissue. The difference isn’t just lexical. An Alvar Aalto chair from 1932, if it has been genuinely used, now carries an aesthetic weight that the chair off the factory floor in ‘32 didn’t have. The wood has darkened where hands rest. The matte finish has lost sheen unevenly; it has learned the body that sat in it. There may be a small repair at the joint between leg and seat, a replaced screw, a reinforcement tastefully done by some intermediate owner. None of this makes the chair worse. It makes it more beautiful, more valuable, more itself. A serious restorer refuses to strip patina, because patina has become constitutive of the object. Restoration is the art of distinguishing damage from history.

A PHP application from 1998, if it has been genuinely used, carries no added aesthetic weight at all. It carries layered workarounds for browsers that no longer exist. It carries validation logic added three times at three different levels because at every maintenance cycle no one trusted what was already there. It carries four-hundred-line functions handling edge cases introduced by customers who stopped being customers a decade ago. No one proposes preserving this condition as part of the product’s value. The industry word for it is technical debt, and the vocabulary gives the game away: debt, not history. Something to retire, not honor. The very words we use to describe our relationship with time reveal that we have no concept for calling an old system beautiful. The best we can manage is “solid,” “battle-tested,” “proven.” These are virtues of resistance, not virtues of accumulation.

The archaeology of old code is an informal discipline every senior engineer practices without ever having studied it, and it has its recognizable constants. There are the compatibility strata for long-extinct browsers: if (window.ActiveXObject) to detect old Internet Explorer, CSS hacks that exploited specific Firefox bugs from before the great rewrites, conditionals checking for window.attachEvent back when the browser field was genuinely plural and incompatible. There are feature flags still switched on for gradual rollouts that were never completed — half the code sitting behind if (feature_active('new_checkout_flow')) and the other half in the else branch, the feature at one hundred percent rollout for seven years, but no one brave enough to cut the dead branch because no one remembers exactly what it did. There are schema migrations begun and never finished, where two columns coexist in the same table, one with the old name and one with the new, both written by the application “just in case,” read selectively depending on where in the code you happen to be. There are functions with names like processOrderLegacy, processOrderLegacyV2, processOrderFinal, processOrderActuallyFinal — a sedimentary log of cleanup attempts, none of which was ever really completed. None of this is patina. It is a sedimentary log of unkept promises, of intentions the business outran before they could be realized. If a furniture restorer found twenty overlapping coats of paint on an 18th-century dresser, each applied without stripping the last, he would not say the object had gained value through the layers: he would say it had been mistreated, and he would propose to remove them. Old code is treated exactly that way even by its practitioners, who call it legacy in a tone that mixes technical neutrality with a faint disdain. The word itself is perhaps the clearest tell of the field’s unresolved relationship with its past: it comes from the Latin legare, “to bequeath,” but in technical use it has come to mean nearly the opposite — something inherited against one’s will. A burden, not a gift.

Environmental drift, not aging

Why? Why do material objects gain something through time, while digital objects seem only to lose? An easy answer is that the difference is ontological: code is pure semantics; it has no material substrate on which the marks of use can settle. Wood breathes, absorbs moisture, oxidizes, wears at points of friction. A byte does none of this. A binary file today is bit-for-bit identical to the day it was written, barring accidental corruption of the storage medium, and that corruption carries no semantic value anyway: it tells you nothing about how the thing was used. The easy answer has the defect of every easy answer, which is to close the conversation at precisely the point where it ought to start.

Let’s go deeper. The reason a chair ages well isn’t that it’s made of wood; it’s that its surroundings remain substantially stable. Gravity doesn’t change. Human physiology doesn’t change. The function of “supporting a seated body” doesn’t change. The modifications the chair undergoes are internal modifications to its fabric, in dialogue with an environment that moves much more slowly than it does. The chair and the world around the chair age together, at roughly the same pace, and the result is a kind of domesticated co-evolution. Software exists in an environment that moves much faster than it does. The browser ships a new major version every four weeks. The language breaks backwards compatibility every two years. Libraries have a shelf life shorter than a parliamentary term. The operating system under it stops existing in the form it was compiled against. Software doesn’t age internally, the way wood does. It progressively detaches from its environment, like a spacecraft that has run out of propellant and watches the station drift away. What we call “software aging” isn’t aging in the chair’s sense. It is environmental drift. It measures the growing distance between a fixed artifact and a context in motion.

This difference is ontologically decisive. A building and its urban context age together in continuous dialogue, and that co-belonging is the very condition on which we can speak meaningfully of “aging” at all. Software has no co-belonging: it has compatibility, which is a much poorer relation. Compatibility means only that two things that don’t speak to each other can keep pretending to, for one more release cycle. When Brand writes that buildings learn, he is describing a process in which the building and its inhabitants modify one another. When a systems engineer adds a compatibility shim to run an old binary on a new kernel, she is driving a wedge between two worlds that have stopped talking, and she is buying time. The shim is the opposite of learning: it is the admission that learning is not possible, and that only the appearance of communication can still be kept up.

Ruskin, and the truth of use

There’s a passage in Ruskin, in The Seven Lamps of Architecture, where he argues that a new building is by its nature false, and only becomes true through the frequentation of years. Ruskin is Victorian, emphatic, often insufferable, but that sentence is one of the most precise things ever said about the built object. The truth of a building lies not in the blueprint but in the history of its use. Apply the same criterion to software and you have to conclude that software never becomes true. It stays in a permanent state of newness even when its compile date is twenty-five years old, because the accumulation of history that would make it real in the Ruskinian sense isn’t possible in its medium. The only thing it accumulates is mounting incompatibility with its surroundings — and that isn’t history. It’s erosion.

The Unix objection

Here we have to face the strong objection — the one every technically literate reader has already been composing in their head, and which, left unanswered, makes everything above suspect. The objection is: Unix is more than half a century old, and not only still works but has become more elegant over time, not less. POSIX, TCP/IP, SQL, the hierarchical filesystem, the pipe. These are all ideas somewhere between forty and sixty-plus years old. They sit at the center of the planet’s digital infrastructure. They don’t behave like the 1998 PHP from earlier. They behave, if you like, exactly like Aalto’s chair: objects that have crossed time gaining, not losing. Something in the argument doesn’t add up.

The objection is serious and deserves a serious answer. The easy response would be to call Unix an exception, an outlier, a lucky case that doesn’t invalidate the rule. That would be a weak response. The more interesting answer is that Unix doesn’t contradict the previous argument but exhibits its exact mechanism, and clarifies a distinction that has so far stayed implicit. The distinction is between software as code and software as specification.

Spec, not code

What we call “Unix” today is not, literally, the software Ken Thompson and Dennis Ritchie wrote at Bell Labs between 1969 and 1971. That code has been dead for decades. The commercial AT&T branch was sold, split, re-absorbed. BSD was forked many times, and every fork has since been rewritten. Linux — today the dominant form of “Unix” in global infrastructure — shares not a single line of code with the original Unix: it is an independent reimplementation, begun by Linus Torvalds in 1991, that exposes the same system interfaces (calls, filesystem structure, conventions) but was written from scratch. macOS descends from NeXTSTEP, which in turn rests on the Mach microkernel and BSD components, and here too the code has been rewritten and recast so many times that material continuity with the starting point is purely ritual. What has survived isn’t Unix’s body; it’s its form. Its interface. Its grammar. The fact that there are system calls named open, read, write, close, working more or less as they worked in 1973, doesn’t mean the code implementing them has aged well. It means the specification defining them has become a different kind of thing from code entirely. It has become culture, convention, shared language, norm de facto and then norm de jure via POSIX.

The same goes for TCP/IP. The protocol survived; the implementation did not, or at least not in its original form. Every modern TCP/IP stack — from Linux to Windows to iOS to the ESP32 powering a smart bulb — has been rewritten or realigned many times over the decades. The 4.4BSD networking code, long a reference base for kernel networking in many systems, has been absorbed, branched, and reimplemented to the point that modern stacks hold a historical rather than material kinship with it. What persists, unchanged, is the RFC: a text document describing, in technical English, how two machines ought to speak to each other. The RFC isn’t software. It is closer to a diplomatic treaty than to a program. That’s why it ages well: it belongs to the same class of objects as a diplomatic treaty, a constitution, a grammar. It is a shared convention whose force comes not from its implementation but from the number of actors who recognize it as binding.

SQL is the most instructive case. The SELECT ... FROM ... WHERE syntax was defined in the mid-1970s by Donald Chamberlin and Raymond Boyce at IBM. Today everyone uses it. But no relational database in production today runs on the original System R code. Postgres is a reimplementation. MySQL is a reimplementation. SQLite was written from scratch in the 2000s and is now probably the world’s most widely deployed database by number of active instances, arguably outnumbered only by Excel spreadsheets. The code implementing SQL has died and been reborn so many times that material continuity is beside the point. What remained is the relational model, which is a mathematical object, and a certain syntax, which is a cultural one. Both detached from the code that first embodied them, and precisely because they did, they were able to cross time.

TeX, SQLite, and the telling exceptions

There are, however, a handful of rare cases in which the code itself seems to have achieved something like patina, and they are worth looking at because they illuminate the general condition by contrast. TeX, the typesetting system Donald Knuth began writing in 1978, is one such case. At some point Knuth declared TeX finished, in the literal sense: no new features, only bug fixes, with the version number converging asymptotically to pi with each release — the explicit intent being that when Knuth dies, the version number will equal pi exactly, and the software will stop changing forever. Knuth offers a small monetary reward, doubling every year, to anyone who finds a bug in TeX, and for many years now no one has claimed it. Not because there aren’t bugs left, but because the software has been used so thoroughly, for so long, that the remaining ones live in corners no one ever visits. TeX works today as it worked in the late 1980s; it compiles the same source files and produces the same typographic output. Its source code, written in WEB (Knuth’s own literate-programming system combining Pascal for logic and TeX for documentation), was published in 1986 as TeX: The Program, Volume B of Computers and Typesetting, and is treated as a literary work. It has been read, commented on, studied. It is one of the rare times code has crossed the threshold from pure implementation into something like specification — but in the concrete form of the program, not in the abstract form of an RFC. Knuth achieved this by imposing an extreme condition on his own work: refuse every evolution. TeX doesn’t age because, in a sense, it chose not to live. It accepted mummification as the price of permanence.

SQLite is the other interesting case, more recent and less mystical. Its developers have publicly declared, in the project’s documentation, the intention to maintain the library at least through 2050, with full backwards compatibility of the C API and the on-disk format. That commitment isn’t boilerplate; it is a concrete constraint that follows from the fact that SQLite is embedded in avionics systems (the Airbus A350 among others), medical devices, and military equipment — all objects whose life cycles exceed forty years. To sustain such a horizon, SQLite has built a test apparatus that, according to figures its own developers publish, runs to roughly ninety-two million lines of test code against one hundred fifty thousand lines of actual library, a ratio of nearly six hundred to one. Every conditional branch is covered by MC/DC tests, the standard used in avionics for DO-178B certification. The code itself is written with explicit attention to the fact that it will be read and maintained by people not yet born. SQLite took duration as a design problem from the start, and has treated the stability of its own interface as an ethical question more than a technical one. The result is a piece of software that has existed for more than twenty-five years, runs on billions of devices, and has never prompted anyone to rewrite it from scratch. It’s a case where the code itself, not just its specification, seems to have aged well. But look a little closer and you see the result was achieved only by accepting constraints the rest of the industry would refuse. SQLite almost never changes, even at the cost of giving up features that would make it more modern. SQLite has no external dependencies, almost as a protest against the way the rest of the world builds software today. SQLite has an internal culture that borders on monastic. In other words, SQLite ages well because it built itself an ecological niche in which the environment around the code has been artificially stabilized. It recreated, inside a small perimeter, the conditions that let an Aalto chair become more beautiful with the years: an environment that moves slowly, a user who pays attention, a culture that recognizes the value of duration. It is no accident that these examples are, statistically, anomalies. They are the exceptions that reveal exactly which conditions are necessary for software to age — and confirm that in the main body of the field, those conditions do not exist.

The body dies, the spec resurrects

Viewed from this angle, Unix doesn’t age well. Unix is continuously resurrected. The body dies and is remade from scratch, starting from a specification that has meanwhile become sacred enough to warrant wholesale rewriting of the body every twenty or thirty years. It has the structure of a religion more than of a material object. Aalto’s chair, to stay with the metaphor, has never been rebuilt from scratch: the chair from 1932 is physically there, dents and all. If we applied the logic of Unix to wood, we would have to say the concept “Paimio chair model 41” survived because Artek, since its founding in 1935, has continued production for over ninety years, and the chairs of 2026 are descendants of those from 1932 without being the same chairs. It would be true, but beside the point: what interests us about the 1932 chair is precisely its material duration, not the persistence of its model. With software it is the opposite. We don’t care about the original code, and no one preserves it as a relic. We care about the persistence of the model, and that persistence requires the periodic destruction and rewriting of the code.

The Unix objection, then, doesn’t refute the argument; it sharpens it. What ages well in the digital isn’t code. It is specifications that have been lucky enough, and well-capitalized enough, to rise above their implementation substrate and become something else. Standards. Stable interfaces. Lingua francas. Most code never reaches that level and cannot reach it. Ninety-nine percent of the software running today will not become POSIX. The custom CRM for a four-hundred-person company will not become SQL. A retail chain’s e-commerce site will not become TCP/IP. Not because it’s badly written, but because it isn’t that kind of object. It is, structurally, implementation. And implementation, in digital, cannot age well, because it has none of the requirements for doing so: no material substrate to register use, no stable environment to persist in, none of the cultural weight that permits periodic reincarnation.

Rewriting isn’t a sin

This distinction clarifies an old debate inside the field that has always been badly framed. In 2000, Joel Spolsky wrote a widely circulated article, Things You Should Never Do, Part I, arguing that rewriting functioning software from scratch is the worst strategic mistake a software company can make. The specific case was good: Netscape had lost the market because it decided to rewrite its browser from scratch, leaving the window open for Internet Explorer for three years. The problem with Spolsky’s essay is that it generalizes from that one case without acknowledging that most software has to be rewritten, sooner or later, because it cannot be maintained indefinitely in the form it was conceived. Unix has been rewritten many times. Linux itself, at the level of individual subsystems, is being continuously rewritten: the scheduler has been replaced, the networking stack has been redone, the filesystem has been rethought. What Spolsky called “never rewrite” was really “don’t lose the continuity of the specification during the rewrite,” which is a very different and much harder thing. A rewrite fails when it loses contact with what the code was doing for its actual users. It succeeds when it preserves the specification and throws the implementation away — the way a Catholic body is buried but the soul moves on.

A dignity denied

If this reading is correct, then the low-grade melancholy running through much of everyday technical work has a structural, not psychological, explanation. We aren’t writing badly. We are writing objects that cannot age, because we don’t belong to the narrow class of artifacts that can rise to the level of cultural specification. Ninety-nine percent of what we write is destined to die without trace — not through poor craftsmanship but through a property of the medium. A thirteenth-century mason knew that a good wall would still be standing in the sixteenth century, and probably much later. A twentieth-century plumber knew that his pipes, with a bit of maintenance, would serve three generations. A developer in 2026 knows that the code she is writing today will, with reasonable probability, be decommissioned within five to seven years. Not because it’s written worse than pipes. Because the pipe and the wall belong to a regime in which aging is possible, and code does not.

This changes the ethical character of the trade in ways we have not yet metabolized. For millennia, building something durable was among the highest forms of dignity in human work. The cathedral, the bridge, the printed book, the violin. Objects made with the consciousness of lasting beyond the life of their maker. Software development is one of the few highly skilled trades in which that dignity is structurally foreclosed. Not because no one works well, but because the medium does not admit that kind of duration. The technical debt we opened with, seen from this angle, is not a defect manageable through better practice, tighter discipline, more rigorous testing, sharper code review. It is the specific form the unavoidable deterioration takes in an artifact that has no other way to deteriorate. It is how software ages badly because it does not know how to age any other way.

The lamp of memory

There is a broader reading here, one that leaves the strictly technical domain and touches something more uncomfortable about the culture we live in. Ruskin, again, identified seven virtues of architecture, which he called lamps. Sacrifice, truth, power, beauty, life, memory, obedience. The lamp of memory was, for him, the virtue of buildings that let themselves be crossed by time without resisting it, that preserve the traces of those who inhabited them, that become, in their way, biographical archives of human passage. A civilization that cannot build objects capable of memory, Ruskin said, is a civilization that has given up one of its fundamental functions: the transmission of itself through its things.

The digital, from this point of view, is the exact opposite of Ruskinian architecture. It is a material culture — if it can still be called that — in which memory doesn’t accumulate in things but leaves them. Five-year-old software is already an antique. A website from ten years ago is no longer reachable; its domain has lapsed, its links are all broken, its images point to decommissioned servers. Digital archives exist only thanks to heroic and marginal efforts: the Internet Archive is a single point of failure for three decades of online culture, and no one has really figured out how to replace it. Our photographs sit on servers we don’t own, in formats that may not be readable in twenty years, protected by service agreements that can be changed unilaterally. Our correspondence is in mailboxes that will vanish when the company hosting them changes business model. The material continuity of human inheritance — imperfectly guaranteed for millennia by the physical persistence of objects — has become precarious in a way no previous civilization had known.

That precariousness is not a side effect but a structural property of the medium. And software, which is at the heart of this new condition, inherits and amplifies the precariousness. It doesn’t age because it cannot accumulate memory in its fibers. It has no fibers. Its only form of continuity is rewriting, which is the exact opposite of memory: the periodic production of a new object that pretends to be the same.

Someone at this point may object that I am dramatizing, that every era has had its precariousness, that papyrus decayed and parchment was scraped and the printed book burns. True — but the quantitative difference is so large it becomes qualitative. The average durability of a well-kept printed book is measured in centuries. The average durability of a digital file is measured in years, perhaps decades in lucky cases. The delta is one or two orders of magnitude. A civilization in which cultural objects last a hundred times less than in the previous one is a structurally different civilization, not merely quantitatively but qualitatively. It has a different relationship with time. It produces a different subjectivity in those who live inside it. A developer knows, in a way a sixteenth-century printer did not, that his work will not outlive him.

The ephemeral objection

There is a less tragic way of reading all this, and it’s worth working through before closing. The objection runs like this: maybe permanence isn’t necessarily a virtue; maybe software is a form of deliberately ephemeral cultural production, in the sense in which a theatrical performance or a jazz set are ephemeral — and their ephemerality is not a defect but a constitutive feature of how they exist in the world. A lambda function that runs for thirty-seven milliseconds and disappears isn’t a failed object because it doesn’t last; it is a fully realized object because it did exactly what it needed to do in the time it needed to do it. The monument metaphor, inherited from architecture, may simply be the wrong fit for the medium, and insisting that software “doesn’t age well” may be like complaining that a thunderstorm doesn’t age well — a category error.

The objection is interesting, but it breaks the moment you take it seriously. The problem is not the code that runs for thirty-seven milliseconds. That really is an event, not an object. The problem is that nearly all the software we depend on in daily life is not an event in that sense: it is infrastructure. The system our bank uses to manage accounts is not a jazz performance. The medical software running the ICU ventilator is not a thunderstorm. The municipal registry database is not an ephemeral function. They are objects that claim to be infrastructure, that we treat as infrastructure, that institutions embed in their processes as if they were infrastructure, and yet that have the durational and memorial properties of a cloud. This discrepancy — between the social function software performs and its material durational properties — is the point at which the question stops being philosophical and becomes civic. A society that entrusts its vital functions to objects that cannot grow old is, quietly, shifting the cost of maintaining its own continuity onto a technical layer that cannot carry it.

Precarious infrastructure, law playing catch-up

Seen from this angle, the European Cyber Resilience Act — adopted as Regulation (EU) 2024/2847, fully applicable from December 2027 — along with the new Product Liability Directive (EU) 2024/2853 and the obligations under NIS2, are clumsy but telling legislative attempts to force software to behave like serious infrastructure. They require producers to define a support period reflecting the product’s expected life cycle — at least five years in most cases — to keep SBOMs up to date, to answer for vulnerabilities introduced into the product even after sale. They are, in a sense, a legislative attempt to impose on software the durational properties it does not naturally have. That these rules exist, and that the industry perceives them as an added cost rather than an acknowledgment of civic responsibility, says something about how deeply developers have internalized ephemerality as a professional privilege. A mason knows he must answer for his wall for many years. A developer is used to answering for her code until the end of the contractual warranty — typically twelve or twenty-four months. The two trades have horizons of responsibility that differ by an order of magnitude, and the difference is invisible in the language we use to describe them.

An ethics of duration

Coming back to the initial question — why software cannot age — we can now give a less lapidary answer. It cannot age because it is made of a material without grain, in an environment that moves faster than it does, inside a productive culture that has given up on considering duration one of the dimensions of value. Each of these three factors is a sufficient cause of the result, and together they make the result nearly inevitable. The first is ontological and probably unresolvable: code will never become wood. The second is systemic and could be mitigated, if the technical culture learned to treat stability as a virtue rather than a sign of being behind. The third is purely cultural, and it is the only one on which we can really act.

Act how? Probably in directions the field currently considers regressive. By slowing release cycles. By preferring backwards compatibility to elegance. By writing less code and more specification. By treating stable interfaces as monuments — objects whose value lies in their resistance to change. By accepting that most code will not become Unix, and that precisely for that reason, it ought to be written with some consciousness of its transient destiny — without the false ambition of duration and without the nihilistic despair of its absence. A trade that knows it isn’t building cathedrals but refuses to build shacks. An intermediate dignity, for which we don’t yet have a good name, and which may be one of the things this generation of technologists should try to articulate.

If there is any consolation in the fact that software doesn’t age well, it is that this property forces us, by contrast, to bring into focus what aging well means in general. It forces us to recognize that the patina on Aalto’s chair is not an automatic fact of wood, but the result of a long relationship between a well-made object, a stable environment, an attentive user, and a culture that knows how to recognize the value of that triangulation. When one of those terms drops out, patina doesn’t form. Wood left in the rain doesn’t acquire patina; it rots. Wood sealed in storage doesn’t acquire patina; it desiccates. Patina is a collective work that requires time, care, and context. Software, as things stand, has none of the three, and the idea that it might sounds like a nostalgic fantasy.

It isn’t. It’s a design question. What would it mean to write code knowing it had to last as long as a wall? We don’t really know yet, because we’ve almost never tried in earnest, and when we have, it has almost always been in domains marginal to the mainstream: avionics, industrial control, legacy banking systems — places where duration is imposed from outside as a regulatory constraint rather than chosen as a cultural value. Civil software — the software that builds the public and private life of most people — has been built on the implicit assumption that duration isn’t its problem. That assumption is becoming untenable just as society is delegating more and more vital functions to software. Among the responsibilities of this generation of technologists, formulating an ethics of duration for the trade is probably among the most serious, and among the least postponable.

What remains, in the end, is the underlying question. Software doesn’t age well. At the start, that sentence sounded like a technical grievance. Arrived here, it’s clear it is something different. It is an exact description of the kind of artifacts we have collectively decided to place at the center of our shared life, and an implicit demand to reckon with that decision. The objects at the center of a civilization ought, within the limits of the possible, to know how to accompany it through time. If they don’t, we should either change them or change the place they occupy. Thus far we have done neither. We have let them occupy the center while behaving as though they were at the periphery, and we have called that condition “progress.” It’s worth starting to call it by a more accurate name.

The author

Andrea MargiovanniCraft

I have been writing software long enough to consider it a craft, not a pipeline. I care about the difference between a technical choice and a default inherited without measuring its cost.

See the guide →