Correctness is a low bar. Most systems that reach production clear it. Plenty of them still turn difficult to touch within a few years, because nobody treated time as a design constraint while there was still time to.
A system lasts when conservative choices made early are kept. What it promises has to stay visible, and so does what it will not promise.
Every system eventually gets read more than it gets written, by people who weren't in the room for the original decisions. That future reader is the software's real audience. Code that leans on shared context asks that reader for a trust it hasn't earned.
The code can keep running on explanations that live outside it, and on invariants nobody wrote a boundary for. Every change still turns into a negotiation with its own past.
Someone opened a helper that computes totals, found two lines in the wrong order, swapped them, and swapped them back, because three callers already depended on the wrong order. The tests still pass. Opening it again means becoming the person who owns the totals.
Embarrassment is a useful metric for catching this early. Once a file can only be explained by apologizing for leftover urgency, or for context nobody wrote down, avoiding it starts to feel safer than touching it.
This kind of embarrassment almost always traces back to overreach. Someone stretched a promise too wide, or baked more certainty into a default than the problem actually had.
Software built to last stays conservative about what it claims to do. It doesn't try to anticipate every future use case, and it won't generalize a function before two real call sites demand it. Repetition is often cheaper than unifying too early. A problem can wait until it's unavoidable. Those are decisions you can still undo.
A default that stays safe under partial understanding gets used correctly far more often than a powerful one that demands real expertise to avoid misusing. Strong assumptions baked into a default expand what the whole system has promised without anyone recording the expansion, and every one of those promises eventually comes due.
Exposing internal detail invites coupling even from well-intentioned callers, and that coupling hardens into dependency soon enough. What was once an implementation choice becomes a contract by accident, and changing it later starts to feel like betrayal.
The systems that survive tend to be the ones that chose, early and often, what not to build. Saying plainly what a system supports and what it puts out of scope is what keeps it legible once other people start changing it.
Once implicit contracts have piled up, no refactor fully restores a system's original tractability. Understanding gets expensive enough that progress just slows to a crawl.
Every other review a system gets happens once, before it ships. Time keeps reviewing it for years afterward, and it never grades on a curve.
Top comments (0)