Tech Debt vs Mess
Software developers often say, “Our system has Technical Debt”. However, a code review will usually tell a different story—the code is a mess: There are plenty of overlong, hard-to-understand functions. Modules are too big, don’t have a clear purpose and are poorly named. The codebase has too much coupling between seemingly unrelated parts.
To the developers, the code appears unnecessarily complicated for what it does. The system looks like it has been in rushed development for years. The symptoms of neglect plaguing it are the usual suspects:
- Features take a long time to implement, and
- bug fixes cause more bugs.
What I have described here is not a system that has Tech Debt. It is a messy system.
The ‘Big Ball of Mud’ comes about over time. It happens so slowly, almost no one notices. It’s a build-up of minor, uncorrected problems—entropy in action. That’s why we need to be constantly vigilant for messy code. It’s the death by a thousand cuts after years of omission and neglect.
Technical Debt is something entirely different. When developers plan and implement a suboptimal design, that’s Tech Debt. They do this consciously and are aware of the trade-offs. They might do this due to deadline pressure. Or because it’s an MVP or prototype.
For example, we are to engineer an HTTP API with an OAuth2 bearer token authentication mechanism. In the interim, we are downgrading to Basic Authentication (i.e. username and password). Why? Because the implementation is quicker and we are under deadline pressure. The less versatile and secure authentication represents Technical Debt.
Technical Debt is directed; developers introduce knowing that it will temporarily degrade the system.
In this way, developers plan and execute Technical Debt as well as any other code we write. We conform to our sound programming practices and do the best possible job we can. We
- write our tests,
- create short, understandable functions,
- design small, pluggable modules.
And we plan to remove the Technical Debt. We put the fixing of it in our Backlog.
So, we carefully introduce Technical Debt with a view of removing it soon. On the other hand, a code mess is an accumulation of years of uncorrected programming problems.