This is a post I shouldn’t have to write.
Technical debt is a common thing. To sum it up in one sentence: technical debt is when you take shortcuts in your development to save time, in a way that will need to be fixed up later.
Why do I feel like I shouldn’t have to write this?
Just about every developer already knows about technical debt, the problems it causes in the long run, and the struggle that they have to get the time to work on it. And yet, it still takes an awful lot of effort to convince managers to give developers that much-needed fix time.
I feel that by now, things shouldn’t be this way. There are enough jokes, horror stories and PR nightmares out there that this particular concept should be understood by everyone. So this is my attempt to be yet another voice that says: listen to your devs, and believe them when they say that your technical debt is worth paying down sooner rather than later.
If you’re a developer reading this, you’re probably all too familiar with technical debt. If you’re a project manager, product owner, or someone else who doesn’t write code, please read on.
What is technical debt?
There’s normally more than one way to solve a problem when developing software. Sometimes the solution is fast to implement but what one might call “hackish”. That is, perhaps the solution doesn’t handle all particular cases, or will cause performance penalties in the long run.
Often, technical debt is caused by time constraints preventing proper solutions from being written. Sometimes it’s a question of skill, where one or more of the developers lacks the technical ability to write an effective solution and their team members need to take extra time to work with their non-optimal implementation.
Once again, technical debt happens when someone didn’t implement the best solution the first time; they’re ultimately forced to come back later and make fixes – it’s now a debt that must be paid.
What triggered this post?
As with many of my anecdotes, I’ll have to anonymise some of these details to protect the guilty. I’ve been working on a project that is built using Library A. Recently version N of Library A would no longer build, having been deprecated. To keep building the project, the library had to be updated to at least version N + 1.
This issue was something that had come up on the actionable radar months earlier, but it wasn’t until the debt actually became a complete roadblock that we were given time to start paying it off. A classic example of how technical debt occurs.
I consider this to be like putting off your mortgage payments until the bank is foreclosing on your house.
It’s something that I’ve seen happen too many times over my many years of development work. The technical debt should never have accumulated to the point where it blocked further development from taking place.
Good technical debt
Is all technical debt bad? Sometimes we can (and should) make shortcuts – provided they’re the right kind of shortcuts.
I wrote recently about the importance of failing fast, and building Minimum Viable Products. When developing these potentially short-lived projects quickly, it’s important to know which corners can be safely cut. The question then becomes: how do we determine which corners those are?
Maybe we can shave off some development time by storing passwords in plain-text. Is this a good idea? No!
Trying to save time at the expense of security is never worth it.
How about if we save a few weeks by hosting our app on a non-scaling architecture that will be fine up to about 100,000 users? That’ll save a lot of time and effort, right? But at that point, won’t we have to migrate to a better system? I would say that tradeoff is fine for a new project, and it’s OK to carry this technical debt. After all, once you get to 100,000 users, the budget should allow for this rework.
While there can be a fine line between good and bad technical debt, the biggest distinction is when you have a plan and a time to pay those debts back.
What can I do as a manager?
Listen to your developers! When they say they need time to work off some of that technical debt, hear them out. Some cases will obviously be higher priority than others; non-performant code should be more important to fix than code that is just ugly. Your developers can help you understand the business importance of what they’ll be fixing.
Just because the debt is not yet affecting the performance of the product doesn’t mean it’s not causing problems. Sometimes badly organised code that needs to be refactored can hamper any developer who works with it. If it’s not as clear as it could be, any time someone is working with it they will be slowed down by trying to understand and integrate with it.
An investment in some time getting the debt manageable and therefore reducing the “interest rate” can pay off with time savings over rest of the life of the project.
And remember: never compromise on the safety and security of confidential data. Technical debt can be expensive, but legal liabilities can cause a true catastrophe for your company.
What can I do as a developer?
Be realistic with your scheduling estimates. During sprint planning, jump up to the next t-shirt size/Fibonacci number to account for implementing a solution without having to take shortcuts. You might be able to treat technical debt as a bug that needs fixing (it kind of is) if your company treats budgets for bug-fixes more leniently than feature implementation.
Reach out to your managers to make sure they understand the technical debt problem, both in concept and in the specific cases of your project. Just because something works now doesn’t mean it’s going to keep working without supervision forever. If you never make the case for needing to fix technical debt then you’ll never get the chance to fix it.
Assign someone on your team to be in charge of monitoring library or SDK deprecation. This is one type of technical debt that you don’t have to work too hard to convince management that a fix is necessary. When you can point out that our product will stop working unless this is sorted, it’s pretty easy to get a budget assigned for a fix.
Finally, the important thing is to discover any deprecations early on, and keep track of ongoing developments in the packages you’re using. There’s nothing worse than being stuck from releasing updates or fixes because you’re blocked by other software that needs updating.
Conclusion
I hope that one more voice can help convince everyone not to ignore technical debt until it’s too late. Start paying it down and reap the dividends from increased team productivity.
Developers – make your voice heard and speak up when you think it’s time to clean up the tech debt. You’ll never get the resources to make all those fixes if you never ask.
Managers – listen to your developers about technical debt. Even if the business-cases aren’t immediately obvious, the payoffs over time can not only result in a more productive team, but a happier one.