There's No Limit to How Bad Code Can Get

This essay critiques metaphors like 'a sinking ship' for bad codebases. Such metaphors are misleading because a business will collapse long before code quality reaches a hypothetical floor, and technical debt has no bankruptcy or clean reset, giving a false sense of security.

Software is abstract, unlike a physical building or bridge. If you keep adding floors and rooms to a building, it will eventually collapse; software faces no such constraint. Code can always get worse, with a new layer of indirection or a reduction in performance.

The author recounts his first ugly legacy codebase as a new graduate at Amazon, working on software that processed orders. On the surface the task seemed simple: write some things to a database and call services owned by other teams to ask validity questions or update bookkeeping. He and his colleagues estimated that two dozen strong engineers should suffice to maintain and evolve it, but the organization had hundreds of people and the system had grown so large and complex that it was impossible to learn entirely.

Institutional knowledge had eroded because few stayed longer than a few years, leaving code full of 'haunted graveyards' where fear suppressed under-rewarded simplification efforts. Business rules for each type of order had been set by people long gone, and could sometimes only be found in a hopelessly outdated file calling itself a 'living document' — often they were not written anywhere findable. Tracing behavior was hard because much of the system lived across team boundaries where code was not easily accessible.

When an obscure process failed, pagers would angrily notify the team that someone in a tangled web of service dependencies was unhappy. This feedback mechanism kept the system afloat, but it remained difficult to change and had abysmal performance, and new layers were constantly added to support the latest Amazon products. The author felt this was unsustainable, leading to the 'sinking ship' metaphor, though he credits the organization with ongoing attempts to fix the architecture, typically starting with a new manager or senior engineer observing that things were amiss.