Software gets built under the assumption that it is temporary. Ship it now, replace it later, move on. Later rarely arrives, and the temporary system becomes the one the business depends on.
Technical debt is a financing decision
Borrowing against future engineering time is legitimate, and like any borrowing it should be deliberate, recorded, and repaid on a schedule. The failure is not taking on debt. It is taking it on accidentally and never acknowledging the balance.
What durability looks like
- Boring dependencies. Fashionable tools age badly; widely-used ones stay maintained.
- Explicit boundaries. Systems that can be replaced in parts outlive systems that must be replaced whole.
- Tests as documentation. The clearest description of intended behaviour that survives staff turnover.
- Observability from day one. A system nobody can see into cannot be safely changed.
The turnover test
A useful question: if the two people who know this system best left tomorrow, how long until someone else could change it safely? If the answer is measured in months, the knowledge lives in people rather than in the system, and the asset is more fragile than the balance sheet suggests.
Why this matters to a holding company
We expect to own these companies for a long time. Every shortcut taken now is a cost we will personally absorb later, which makes the argument for building things properly less philosophical and considerably more direct.
