↓Skip to main content

All systems eventually collapse ⛓ïļâ€ðŸ’Ĩ

#simplicity #softwaredesign

I believe that all systems eventually collapse under their own weight.

As time goes by, any system that is actively used and developed tends to become larger, more complex, and more inter-dependent. At some point, continued development has slowed down to a crawl. The system becomes a zombie and eventually dies.1

Even if we are perfect designers and developers, we just cannot get rid of all complexity. As suggested by the law of conservation of complexity:

Every application has an inherent amount of complexity that cannot be removed or hidden. Instead, it must be dealt with, either in product development or in user interaction.

To make things worse, any system that serves its users well will naturally expand to gain more features over time. This means that the amount of essential complexity2 will only ever increase.

John Ousterhout expresses similar concerns in A philosophy of software design.

Complexity will still increase over time, in spite of our best efforts, but simpler designs allow us to build larger and more powerful systems before complexity becomes overwhelming.

The only way we can combat the eventual collapse is to try to slow down the process. That is why good software design and sound development principles are so important.

We should make an effort at keeping things simple3, to avoid unnecessary features4, and to remove things that are no longer needed5. It will be the difference between the system you cannot even understand six months later and the system that keeps slowly evolving for decades.

Updates #

  • 2025-03-11: Original post published.
  • 2025-08-22: Added “black hole” footnote.

  1. Glyn Normington provided a humoristic description of the eventual collapse in a Mastodon post.

    Sounds a bit like a black hole. A piece of software so massive that it collapses to a singularity and all you can see are deployments and marketing materials frozen in time on the event horizon. The perspective of a developer of such a system is rather different as project velocity tends to zero while the pressure of fighting bugs tears you apart.

     ↩︎

  2. The idea of “essential complexity” and its sibling “accidental complexity” where introduced by Fred Brooks in his paper No silver bullet. ↩︎

  3. I’ve written several posts on the idea importance of keeping things simple, such as The secret of good programming, As little as possible, and Does this scale down?. ↩︎

  4. Java architect Joshua Bloch’s advice on API design is a good mantra for product design: “When in doubt, leave it out.” ↩︎

  5. “Perfection is finally attained not when there is no longer anything to add, but when there is no longer anything to take away”. I wish more developers and product managers had the courage to remove things that are not absolutely necessary. ↩︎