On Building Things That Last in a Culture of Disposability

Why is disposability the default in technology culture?

Because disposability aligns with market incentives. Replacing systems generates revenue. Maintaining them does not. The cultural bias toward novelty is not an aesthetic preference. It is an economic structure that rewards replacement over repair.

I maintained a data processing system for 6 years. By the third year, the team was pushing for a rewrite. The system was “old.” It used “outdated” patterns. The code was not “modern.” But it processed 1.4 million records daily with 99.7% reliability and had not required a production incident response in 14 months. The system was not exciting. It was excellent. And excellence, in a culture that values novelty, looks like stagnation.

The push for a rewrite was not driven by technical necessity. It was driven by cultural discomfort with the old. The new system, when finally built 2 years later, achieved 99.4% reliability in its first year, processed the same volume, and cost 3x more to operate. The rewrite was not an improvement. It was replacement for the sake of replacement.

What does it mean to build things that last?

It means optimizing for longevity rather than novelty: choosing stable technologies, writing code for future maintainers, documenting decisions, and designing systems that age gracefully rather than requiring replacement when the team that built them leaves.

I have developed 4 principles for building durable systems:

• Choose boring technology: As I explored in the case for boring technology, technologies with 10-year track records are more likely to be supported in 10 years than technologies released last quarter. PostgreSQL, for instance, has been in continuous development since 1996. It will outlast any trendy alternative.
• Write for the reader, not the writer: Code that is easy to write is often hard to read. Code that is easy to read ages well because future maintainers can understand and modify it. The investment in readability pays dividends across the system’s entire lifespan.
• Document the why, not just the what: Code shows what the system does. Architecture decision records show why. The why survives personnel changes. The code without the why becomes an archaeological artifact: present but incomprehensible.
• Design for graceful degradation: Systems that last will encounter conditions their designers did not anticipate. Systems that degrade gracefully under unexpected load, unexpected input, or unexpected failure modes last longer than systems that assume ideal conditions.

What is the Stoic argument for durability?

The Stoics valued things that endure because endurance reveals true quality. Seneca wrote that time is the judge of all things. A system that survives 10 years of changing requirements, team turnover, and technological shifts has demonstrated a form of excellence that no benchmark can measure.

There is a Stoic pride in the system that just works, year after year, without demanding attention or celebration. It is the engineering equivalent of what Marcus Aurelius called “doing the right thing without needing to be seen doing it.” The durable system does not announce itself. It serves, quietly, while attention goes to the latest feature release.

The Japanese practice of kintsugi, repairing broken pottery with gold, embodies a similar philosophy. The repairs are not hidden. They are celebrated as part of the object’s history. A codebase with visible repairs (well-documented patches, clearly marked workarounds, honest comments about technical compromises) is more trustworthy than a codebase that pretends it was born perfect. As I explored in amor fati and legacy code, loving the system as it is, scars and all, is a form of engineering maturity.

How do you resist the culture of disposability?

By measuring system value over time, not at launch. By rewarding maintenance alongside creation. By asking, before every rewrite decision, “is this system failing, or am I bored?”

I now apply a rewrite test: before approving any system replacement, I require a documented answer to 3 questions. What specific problems does the current system have that cannot be fixed incrementally? What is the total cost of the rewrite, including opportunity cost and productivity loss during migration? What is the probability that the replacement system will still be better than the original 3 years from now? If the answers do not clearly favor replacement, the current system stays. According to the wabi-sabi aesthetic, imperfection is not a reason to discard. It is a sign of life lived.

“The question is not whether the system is new. The question is whether the system serves.”

Building things that last is an act of discipline in a culture that rewards the new. It requires resisting the seductive pull of the rewrite, the allure of the latest framework, and the cultural pressure to replace rather than repair. The durable system will not win awards. It will not appear in conference talks. It will simply work, year after year, serving the people who depend on it with the quiet reliability that is the highest form of engineering virtue. Wabi-sabi teaches us to see the beauty in what endures. Stoicism teaches us to build it.