Products that last

Most software is not killed by a dramatic failure. It is abandoned slowly, because nobody can safely change it any more, or because the people who knew why it was built that way have moved on and took the reasons with them. Durability is rarely the thing anyone is assigned to work on, and it is usually what decides whether a product is still running in five years.

In practice it comes down to legibility and honesty. Legibility means choosing the plain version on purpose: the obvious control flow, the explicit conditional, the dumb reliable database constraint instead of the clever in-memory trick. That choice is defended from the failure mode rather than from taste, because taste arguments are unwinnable and failure-mode arguments end in agreement. Honesty means monitoring that reflects what your users actually experience, and alerts that do not spend their credibility paging you over nothing.

The same logic applies to teams, which is why this pillar covers both. Code that a tired stranger can change safely and a team that keeps its context are the same bet made twice, and both are the sort of investment that looks unimpressive right up until the moment it is the only reason the product survived.