The Long Now of Software

Most software is built as if next Tuesday is the only day that matters. Sprints are measured in weeks. Roadmaps are drawn in quarters. The phrase long-term, when it appears in a planning meeting, usually means “the back half of this calendar year.” Anything beyond that is treated as fiction — the kind of thing you discuss politely and then quietly remove from the spreadsheet.

I have spent the better part of a decade inside this rhythm, and I’ve come to think it is doing something quietly corrosive to the craft. Not because short cycles are bad — they aren’t — but because the relentless emphasis on what we are shipping next leaves almost no oxygen for the older, slower question that sits underneath all of it: what are we building that will still be here in ten years?

This essay is an attempt to take that question seriously.

What lasts

The software I find myself returning to, year after year, has very little in common on the surface. A plain-text editor. A command-line tool for renaming files. A wiki I started in 2014 that still works exactly as it did then. A static-site generator whose author has not pushed a commit in three years and whose output I trust more than anything that updates weekly.

What these tools share, I think, is a certain posture toward time. They were built by people who assumed — correctly, as it turned out — that the work would outlast the moment of its making.¹

This posture is rarer than it sounds. Most software is built with the opposite assumption baked into its bones: that whatever ships this quarter will be replaced, rewritten, or rebranded inside two years, and so the deeper questions of durability — will this still make sense to a stranger in 2034? will the data still open? will the URL still work? — can safely be deferred.

The trouble with deferring those questions is that they don’t actually go away. They just get answered by default, and the default is almost always no.

The cost of short horizons

Consider what a short horizon does to a piece of software, slowly, over time.

It encourages dependencies that are convenient now and abandoned later. It rewards features that demo well and punishes the ones — accessibility, error messages, documentation — that compound only after years of use. It makes “rewrite it” the easier answer than “understand it.” It produces, eventually, the strange archaeological landscape that anyone who has worked at a large company knows by heart: layer upon layer of half-finished migrations, each one started with great enthusiasm and abandoned the moment the next migration became fashionable.

A codebase, like a city, mostly reflects the timescales of the people who built it. Short attention spans produce short streets.

None of this is anyone’s fault, exactly. The incentives all point one way. Performance reviews reward visible shipping. Investors reward visible growth. Conference talks reward visible novelty. The slow, unglamorous work of building something durable — the work that, by definition, you cannot point to until years later — has almost no constituency.

And so the codebases get bigger and the half-life gets shorter and the people who genuinely care about the long view either learn to translate their values into the language of the quarter or, more often, drift quietly into other rooms.

Three habits

I want to be careful here, because it is very easy to write an essay like this and end up sounding like a man complaining that the kids today don’t appreciate hand-cut dovetails. That isn’t the point. Most software, most of the time, is fine being short-lived. A marketing site for a one-week campaign should not be built like a cathedral.

But some software is meant to last. The notes app you use every day. The internal tool a hundred people depend on. The library that other libraries depend on. The personal site you’d like your future self to still recognize. For those, the short-horizon habits are not neutral; they are actively destructive.

A few habits, in my experience, push back against this drift. None of them are clever. All of them are slightly annoying to do.

1. Write down why, not just what

Most code answers the question what does this do. Almost none of it answers why does this exist. Six months later, the what is recoverable from the code itself. The why is gone forever unless someone wrote it down.

The form doesn’t matter much — a comment, a commit message, a markdown file in a docs/ folder, a one-paragraph note in the issue tracker. What matters is that there is a thread, somewhere, that a future stranger (often: you, in two years) can pull on to understand the shape of the decision.

I have come to think of this as the single highest-leverage habit in long-lived software. It costs about two minutes per decision and saves something on the order of two days per archaeological dig.

2. Prefer fewer, older dependencies

Every dependency you take is a bet that someone else will keep maintaining their code at roughly the pace you keep maintaining yours. Sometimes this bet pays off. Often, especially in the JavaScript ecosystem, it doesn’t.

The simplest heuristic I’ve found: when choosing between two libraries that solve a problem equally well, pick the older, more boring one. Boring libraries have already survived the years of churn that the new shiny one is about to enter. They are statistically more likely to still exist in 2030.

# A useful, slightly cynical question to ask before `npm install`:
# "Will this package still be maintained when my child starts kindergarten?"

This is not a rule against new tools. It’s a rule against unnecessary new tools. The cost of a dependency is paid not at install time but five years later, at 2 a.m., when something breaks and the original author has moved on to a different ecosystem.

3. Treat URLs as promises

Cool URIs don’t change.² Tim Berners-Lee wrote that in 1998, and it has aged better than almost any other piece of writing about the web.

A URL is a promise you are making, in public, to anyone who links to your work. When you change a URL without a redirect, you are quietly breaking that promise — not visibly, not in a way anyone will yell at you for, but in a way that compounds. A site that has kept its URLs stable for a decade is a site that has accumulated trust: trust from search engines, from other writers who linked to it, from readers who bookmarked something years ago.

A site that rearranges its URLs every redesign is a site that, eventually, no one bothers to link to anymore. The signal it sends is: I am not here for the long haul. And readers, even unconsciously, hear it.

What endures online

If you walk through the parts of the web that have lasted — personal sites kept since the late nineties, small wikis run by single people, the documentation pages of projects whose maintainers come and go without breaking the pages — a quiet pattern emerges. None of these places are finished. They are tended.

Tending is a different posture from shipping. A shipped thing is complete; a tended thing is alive. You return to it, you fix the small breakages, you add a paragraph, you remove a dead link. The work is never dramatic. Most weeks it is invisible. But across years it is the difference between a site that compounds and a site that decays.

The interesting thing is how little of this requires technology in any meaningful sense. The tools have changed every five years for thirty years. The habits have not. A person who tended their corner of the web in 1999 with hand-written HTML and a person who tends theirs in 2026 with a static-site generator are doing essentially the same job, in essentially the same spirit. The medium is incidental. The posture is the point.

This is, I think, why the long view feels almost spiritual when you stumble into it from the inside of a sprint-driven team. It is not a productivity hack. It is not a methodology. It is closer to a way of relating to your own work — one in which the work is allowed to outgrow you, and you are allowed to be a steward of it rather than its sole author.

The aesthetic of permanence

There is, I think, a kind of aesthetic that follows naturally from taking the long view. It is not the aesthetic of minimalism — minimalism is often just maximalism with a smaller color palette — but something quieter.

It looks like:

• Pages that load instantly because they are made of text and a stylesheet.
• Designs that look fine in a browser nobody has heard of.
• Features that do one thing well and do not grow.
• Words that explain themselves without needing a tooltip.
• Defaults that are kind to the reader.

You can recognize software built this way within about ten seconds of using it. It feels, for lack of a better word, unhurried. It is not trying to convert you, retain you, or upsell you. It is simply trying to do the thing you came for, get out of your way, and still be there next year.

The web’s best rooms are the ones with the fewest lights on. The same is true of software.

I am aware this aesthetic is unfashionable. It does not photograph well. It does not produce dashboards full of upward-sloping graphs. It does not, frankly, scale into a venture-backed business in any obvious way.

But it endures. And for the kind of software I most want to build — the kind I’d be proud to point to in a decade and say “yes, that’s still mine, and it still works the way I meant it to” — endurance is the only metric that matters.

What the long view looks like in code

It can help to make this concrete. The long-view habits are not abstract; they show up in the small, daily decisions of a codebase. A few examples I’ve collected from work I’ve returned to with gratitude, and from work I’ve returned to with regret:

Habit	Short-horizon version	Long-horizon version
Naming	getStuff()	loadPublishedPosts()
Errors	throw new Error("oops")	throw new Error("post not found: " + slug)
Config	hardcoded in three files	one module, one source of truth
Tests	none, “we’ll add them later”	a handful of tests at the seams
Dates	new Date().toISOString().slice(0,10) everywhere	one formatDate() helper

None of these are heroic. None of them require a refactor. They are simply what the work looks like when you assume someone — possibly you — will be reading it in five years.

The interesting thing is that the long-horizon column is almost always easier to write, once you’ve internalized the habit. It is not slower. It is just less default. The defaults of most editors, most tutorials, and most code reviews quietly nudge you toward the left column. Resisting that nudge is most of the work.

// A small example: the date helper above, written once, used everywhere.
export function formatDate(iso: string) {
  return new Date(iso).toLocaleDateString("en-US", {
    year: "numeric",
    month: "long",
    day: "numeric",
  });
}

It took ninety seconds to write. It will be used hundreds of times. The first time the design system changes, every date on the site will update from a single line. That is what compounding looks like in code.

A modest practice

I’ll close with the smallest possible version of this idea, because I think the smallest version is actually the most useful.

Once a quarter, open something you built more than two years ago. Read the code. Use the thing. Read the docs you wrote. Notice what has aged well and what has aged poorly. Notice which decisions you would make differently now, and — more importantly — which ones you would make exactly the same.

This takes maybe an hour. It is not a sprint. It produces nothing shippable. But it does something the sprint never can: it forces you to think on the timescale of the work itself, not the timescale of the calendar.

Over time, this practice will quietly reshape what you build. You will start, almost without noticing, to make different decisions. Smaller dependencies. Clearer comments. URLs you can defend. Features you can live with for a decade.

You will, in other words, start building software for the long now.

---

1. A friend describes this as "writing software the way you'd plant an oak tree." You won't be the one sitting in its shade, and you should plant it anyway. ↩
2. Cool URIs don't change, W3C, 1998. Worth re-reading once a year. ↩