There's No Limit to How Bad Code Can Get
A veteran engineer argues that metaphors like 'sinking ship' and 'collapsing building' mislead us about technical debt. Drawing on years at Amazon wrestling with a sprawling legacy system, he explains that while a business can fail, code has no floor: it can always get worse. Technical debt has no bankruptcy, no clean reset, so we must stop pretending an escape hatch exists and instead actively maintain quality.
Software is in the domain of the abstract. It is not like a building, or a bridge, that is in the physical realm where you can see and feel the nature of the thing. If you continue to add floors and rooms to a building forever, it will collapse. Software faces no such constraint. The code can always get worse. There can always be a new layer of indirection or a reduction in performance.
- ChrisMarshallNY
One of my first jobs, was as a maintenance engineer, on a 100KLoC+ codebase of 1979s-era FORTRAN IV.
No comments.
No subroutines (what we now call “functions”).
No variable name longer than 4 characters.
Fun. The most effective debug tool, was a Ouija board. It made me an expert WAGger.
It was the main reason that I am so anal about code Quality, these days. I never want to subject anyone else to that.
BTW: with today’s LLMs, there’s really no excuse for badly-documented, or badly-formatted code. You can write a thousand lines of commercial-grade spaghetti, and tell the LLM to format and document it.
- lukasgelbmann
Insightful article. The author makes some great points about the dynamics of technical debt in organizations.
I think a sinking ship is a reasonably good metaphor though. A sunken ship is a horrible, terrible outcome.
In the metaphor, a codebase is sunken when it’s unviable to continue using it. The organization stops working on it and no longer runs it. At this point, the code is completely worthless to the business, like a ship at the bottom of the ocean. True, you could imagine the code getting worse theoretically. But in reality, it will just sit there and rot.[0] The business might attempt a rewrite or just discontinue the product.
It’s possible, but not a given, that a business sinks with one of its codebases. This can happen with a ship too, if a business relies heavily on it.
- blevinstein
> Technical debt has no bankruptcy, no clean reset
There definitely is a technical debt bankruptcy option.
You can stop using a particular piece of code or technology, e.g. by replacing it (with new code, or a third-party/vendor solution), or re-architecting a system or business process so that the code's function is no longer needed.
This is exactly what the technical debt metaphor means. Short-lived systems can accumulate a lot of technical debt without as much concern, because you're planning to declare bankruptcy (deprecate and decommission) the code soon anyways; long-lived systems must plan to pay off their technical debt on the usual installment plan.
- socalgal2
2 things
1. LLM can fix this in my experience. an LLM, especially the more modern ones, have way more short term memory than most humans (or at least way more than me). They can dig through this kind of code and figure out all the edge cases, write test, suggest various paths to make things better and then execute on those paths. On request they will happily setup dev systems, staging systems, whatever it takes to make the transition safe. At least that's my experience. They can dig much further than I ever would.
2. Short of and maybe separate to the LLM fix, this pattern of technical debt I think is nearly inevitable, at least with humans. In a perfect world, every human and every reviewer knows exactly what architecture to write and what tests to convey all of the rules and assumptions because no matter what, people are going to leave. I've never seen that code base though. So the rules and assumptions are at best half written down, maybe in some comments or docs, comments or docs that the next person to edit that part of the code base may or may not see. And so it goes.
I work on a code base that runs on Windows, Mac, Linux, Android, iOS. Those OSes change over time, their requirements change, their APIs change, the world changes and new APIs are needed for new things people do, and our original choices for cross platform solutions, no longer fit perfectly. We need to keep moving and shipping and we can't just stop the world and re-architect. Further, like the OP, not eve […]
- cebert
If you have ever worked with low-cost offshore contractors, you know this it true…