Impermanence and the Art of Building Things That Don't Last

Somewhere in a landfill or a decommissioned data center is the hardware that ran the first website I ever built. The site itself is long gone, its domain resold years ago to someone selling something unrelated. I spent weeks on that project as a teenager, convinced it mattered. In the strict sense that anyone remembers it exists, it did not survive the decade.

Nothing in This Field Is Built to Last

Software is unusual among crafts in how openly it admits its own impermanence. A stonemason's arch can stand for a thousand years. A carpenter's table gets handed down generations. But the average piece of production code has a half-life measured in months before someone rewrites it, and the platforms it depends on are themselves being replaced on a similar timeline. We build on shifting ground and call it an industry.

For a long time this felt like something to fight against - a reason to chase the most durable architecture, the most future-proof stack, as if enough foresight could exempt your work from decay. I have come to think that instinct is a category error. It treats impermanence as a design flaw to be engineered around, rather than the actual nature of the thing you are working with.

You do not get to opt out of impermanence by building carefully enough.

What the Monks Already Knew

There is a Buddhist practice of building elaborate sand mandalas over days of careful, meditative work, only to sweep them away the moment they are finished. It looks, to an outsider, like an act of self-sabotage - why spend that effort on something you intend to destroy? But the destruction is not incidental to the practice. It is the practice. The mandala is not made to last. It is made to teach the maker something about attachment, by forcing them to release the thing they just poured themselves into.

I don't think software needs to be swept away on purpose to make the same point. It gets swept away regardless - by new frameworks, changed requirements, companies pivoting or dying, users moving on. The lesson is available to anyone paying attention, whether or not they went looking for it.

The value of the work was never really about the artifact surviving. It was about who you became while building it.

Building Anyway

None of this is an argument for carelessness. You should still write the clean function, still think through the edge case, still care about the person who inherits this code - even if that person is only you, eighteen months from now. But you can hold that care lightly, without needing the thing you built to outlive its usefulness in order to justify the effort you put into it.

What I actually kept from that first website was not the site. It was the version of myself who learned, for the first time, that he could make something out of nothing but a blank editor and stubbornness. That part didn't get decommissioned along with the server. Everything I have built since has been temporary in the same way, and I have stopped expecting it to be otherwise.