What is technical debt and how much do I owe?
If seemingly simple features are taking longer and longer to implement -it’s time you understood why.
A lot of people in tech startups, mostly engineers, but sometimes product managers speak about “tech debt” as if it were some mysterious, sinister and powerful opposing force. A malevolent opposition to all the great things we want to accomplish.
We would have delivered this feature on time, but there’s just so much tech debt… We need another two sprints.
As time goes on, if this is a recurring problem, you and your team members will be tempted to “do more planning” as a mitigation strategy against this aforementioned force. However, facing the truth, that is, that your codebase has a plethora of problems can be too uncomfortable. So the time negotiated for, specifically to deal with the tech debt problem, is squandered.
We white-boarded the modular, ideal, distributed, and service-based system for days, it was great! We were all aligned, but right after our kickoff meeting… the tech debt, it, it… came to my house, finished the loaf, and punched my cat in the face. I have nightmares. Also, we need more time.
When there’s a conceptual gap between, how a system should work as understood by your users, and how it actually works, including all of the convoluted only-sometimes-invoked edge cases, but most importantly, the complex and potentially outdated details that you’re tempted to omit when summarizing the system…Congratulations. You’ve got tech debt!
The larger the conceptual gap, as in, the more “why do I need to think about that when working on this” moments you have, the more tech debt you have. Unfortunately, this is highly subjective and requires building a detailed picture of your application's business logic. Not only do you need a detailed understanding of the exact technical reality of your existing system, but you also need the fuzzier, but conceptually simpler, understanding of how your users truly use your system.
Given all of that, if you now are wondering if your system has tech debt, fortunately, there’s an easy way to start tackling the most simple aspect of it. Measure the potentially outdated details. Simply speaking, delete your unused code.
How can you be sure that your old code is actually old code? How can you know it won’t break anything on production? We will track which code paths and views are invoked on your production server, that’s how. With Coverband.
If you are technically inclined, see my next article detailing how to use it, gotchas, and lessons learned.
