Kellan Elliott-McCrea, a recognized tech blogger, recently wrote “Towards an Understanding of Technical Debt.” In the post, he posited that the term ‘technical debt’ is hopelessly overused, covering too many different types of problems with code. Why should we care? If we don’t clearly understand a problem, we can’t solve it. By putting every type of code problem into the technical debt ‘bucket,’ we not only can’t come up with a single description, we probably can’t find a way to solve the problem.
Having a scientific background, the blog reminded me of the problem of cancer. To lay people, cancer is one dreadful entity that might strike your skin, your breasts, your brain, etc. But to your doctor, each type is different and requires different approaches and treatments. We’ve bundled a large variety of problems into one bucket, cancer, simply because they share a single issue: uncontrolled cell growth. Issues that fall into the technical debt ‘bucket’ also share a single issue: code that no longer works optimally for the present day situation.
Back when the medical profession had a less sophisticated understanding of cancer, more people died. No one is likely to die from bad code, but it’s not too much of a stretch to understand that your job life may depend on fixing it. When code isn’t efficient or can’t be modified to address business needs, your company’s competitiveness suffers. When less revenue is available, the company can’t afford to grow, or sometimes even stay the same size. The company looks for ways to survive on less until they can turn things around. That ‘less’ may mean offshoring or worse, so we need to start by understanding the problem(s) so we can pose specific solutions to each problem that falls under the umbrella of technical debt.
Elliott-McCrea talks about five categories of debt (check his article to read full descriptions):
- Maintenance work―regular work that probably should be simply considered necessary.
- Features of the codebase that resist change―he’s describing how the problem we coded for changes over time but that the way we solved the initial problem makes it hard to alter.
- Operability choices that resist change―this includes code that is so fragile that it breaks when you try to modify it. But it also includes process issues, such as poorly designed testing, lack of staging environments, no policy of measuring results and more.
- Code choices that suck the will to live―Elliot-McCrea describes these as the kind of code you don’t even want to look at―the ‘spaghetti’ code.
- Dependencies that resist upgrading―an example of this is an archaic language that doesn’t support new things you want to add to the system.
Clearly, as each version of ‘technical debt’ represents a very different problem, we need a unique solution for each. One solution doesn’t fix all problems, any more than any one cancer treatment can cure all cancers. For operability choice issues, we have to consider process more than anything. How can we fix the process to make sure that code that moves to production is robust and well-performing?
For developers, the area they can focus on is making the code better. But when faced with thousands of lines of code they didn’t develop, it can seem daunting to even consider approaching it. Some companies have tried ‘rip and replace,’ but this has been costly, time-consuming and fraught with risk. They’re moving from code that worked to a completely new system. Even if they buy a solution, the original applications were customized for their business, and they’d have to do the same with the product. So many people just get stymied at this point.
What’s the answer? For categories 2, 4, and 5, the best option is remediation and refactoring―but not manually. Just like rewriting the code, there’s simply too much risk and cost. Once you recognize that you have code that doesn’t work well and will impede your future growth, you can see the value of investing in solutions that will automate the process of remediation and refactoring. Check out CM M3 for an automated, yet customized solution to the part of technical debt a developer can actually fix.
Did you like this article about “TECHNICAL DEBT:” – email us future blog topics to info@cmfirstgroup.com
