Technical Debt is our Moral Obligation
You can’t maintain a codebase that belongs to a defunct company.
This is the tension at the heart of technical debt. We owe something to the developers who’ll inherit our code — comprehensible architecture, clear commit history, documentation where the intent isn’t self-evident. Edith Brown Weiss called this intergenerational equity: each generation serves as both trustee and beneficiary of what came before1. Software works the same way. Every architectural decision we make constrains or liberates the people who come after us.
But spending too much time as trustee can kill the trust. If we optimise for future developers at the expense of shipping, the company may not survive to have future developers at all. The obligation to future developers is partially discharged by ensuring their existence in the first place.
The answer is necessarily a compromise. Ship working software. Leave breadcrumbs — a clear commit history so future developers can understand why decisions were made, ADRs2 for the choices that aren’t obvious from the code alone, comments where intent diverges from implementation. Not a pristine codebase but a survivable one, with a map.
The obligation is real, but not absolute. Sometimes being a good ancestor means shipping the messy code that keeps the lights on.
Weiss, E. B. (1989). In Fairness to Future Generations ↩︎
Though as I’ve argued elsewhere, what we consider “time not spent on useful work” may actually be essential to long-term team health. ↩︎