Technical Debt 101
If you’ve done any work in software development , technical debt is a concept you probably have experienced first-hand, even if you didn’t know its name. Technical debt is a deep subject, and this post is only a high-level explanation of the concept for those who may not be familiar with it. I’ve also included some of my personal opinions and thoughts based on my development experience.
As the Lead Software Engineer, it’s part of my daily responsibility to identify technical debt and minimize the risk from it. Every decision made within our ecosystem has some impact on our technical debt, whether planning how to repay old debt, ensuring our current actions don’t take on new debt, or determining that taking on new debt is a reasonable action for us at the time.
Let’s start with how I choose to define technical debt:
Technical Debt is the implied cost of future work caused by implementing an easy, but not ideal solution, now, as opposed to a more complex or flexible solution that may take longer.
There are many other definitions, but this is the one I like. When explaining it to others, I relate technical debt to financial debt. By that I mean that it can accrue “interest” and the longer you take to repay it, the more effort or time it will take to pay it back to naught. But unlike a financial debt, where your loan is from a third party, you’re usually “borrowing” time from your future self.
Why is technical debt so bad?
Technical Debt is bad in the same sense that financial debt is bad. Even though you can function while in debt, your debt will follow you. If your debt is reasonable, you can probably carry it indefinitely, as long as you pay just enough regularly that it doesn’t create bigger problems. However, if you ignore it, it can be an overwhelming monster to try to wrangle, and sometimes can cause more or worse problems than you solved by taking on the debt in the first place.
Technical debt can be extremely problematic when it comes to system advancement. If you’re building upon an existing system, that system’s debt weighs into every decision you make. For example, if your system is relying on outdated technology, you need to be sure that technology can support your new plans. If it can’t, you must repay the debt by resolving that technology dependency before you can accomplish the project’s goals. If you have to change all of your system’s underlying framework to support an upgrade, that’s a rather large undertaking. If that debt wasn’t properly managed or accounted for, it can cause missed deadlines and rushed work. In an absolute worst-case scenario, it can cause the project to fail completely.
Where does technical debt come from?
Based on my experience, deadlines are the biggest reason a team willingly takes on technical debt. Go-live dates that are set in stone can force a team to make decisions that immediately creates required rework, but allow the deadline to be met successfully. From my perspective, it’s easier for me to assume technical debt now if I believe there is enough buffer before the next due date to pay it back. I get worried when the deadlines don’t afford me the ability to repay the debt in manageable chunks. Not only is this a recipe for bad system architecture, it can also lead to code quality issues in the long run.
Third-party dependencies are another source of technical debt. If your system needs to upgrade to leverage new functionality or bug fixes, the debt could be as small as regression testing. But it could also include an extensive refactor of your own code to use the newer library, if there are breaking changes. In worst-case scenarios, the scope of debt could be forking the library (assuming you can legally do such), and then maintaining it yourself as your own code, or abandoning it and rewriting the functionality yourself.
Technical debt can also be assumed on your behalf (or imposed upon you) by someone outside of the technical team. Executive decisions, Stakeholders, Business Analysts, Security Departments and Analysts, and even your own IT department can introduce technical debt to your project, sometimes without your knowledge or consent.
There are many other reasons beyond these why a project might accumulate technical debt. I could keep giving examples, but I think you get the point.
How do we better manage our technical debt?
Just like life, sometimes debt is inevitable. But there are a few places where technical debt can be at least recognized and minimized, if not completely rejected.
The Development Team is the first line of defense against technical debt. Here are some examples of where the team’s actions can impact technical debt:
· Questioning the requirements — This sounds a lot like “not understanding the requirements” but it’s not the same. What I mean is perhaps the team doesn’t understand why they’re being asked to do something, and chances are they won’t invest the time and effort to do it well. I’m not saying that the development team should start fights against the requirements, but a simple “why am I being asked to do this?” sanity check goes a long way. Understanding what you’re being asked to do (both short- and long-term) can help you make decisions that will save you interest on your debt or avoid some of it entirely.
· Code Quality — When you have someone breathing down your neck screaming “FIX IT! FIX IT! FIX IT!” it’s very tempting to just throw a quick “that’ll do” type of fix out, without fully investigating the problem and/or testing other aspects affected by this change. Some might argue that this is “quality debt” instead of technical debt. In my opinion, quality debt in software is still a type of technical debt, and the outcome is the same regardless of what you call it.
· Short Cuts — This isn’t the same as code quality, but they are related. You can have high-quality short cut solutions that still result in technical debt. If the effort to build out a new aspect of your system is large, but instead you can append it to existing code somewhere it may not really belong, this can create technical debt to build it properly later.
The Business can also take action to help prevent technical debt. By “The Business” I mean the Product Owner, Stakeholders, Executive Management, or anyone else that isn’t contained within the team responsible for the technical implementation. They are the people with the vision for the project, and also determine the requirements. The Business’s prioritization and decisions will have major impacts on how the development team does its work and makes its decisions. Here’s where the Business can impact the technical debt accrued by the team:
· Deadlines — It’s on the Product Owner and the Business to set reasonable deadlines and adjust them accordingly if the technical debt needed to meet them is too large. It is the responsibility of the development team to communicate this so the Business understands the impact of their decisions.
· Project Goals— This is the responsibility of the business and the development team together. Technical decisions are made based on the known goals. However, only the Business establishes these goals. Without that knowledge or vision, the technical decisions being made are just wild guesses that can have scattered results.
Just like life, proper planning goes a long way. Being proactive, both from the Business and the development team can really help meet your project’s goals, without burdening you or your teams under tons of unnecessary technical debt.
These aren’t the only sources of technical debt, nor are these the only answers, but just a little bit of preparation and focused effort can go a long way in keeping your team’s debt in check, and making your project successful in the long run.
I’m open to hearing what others may have to say about this topic and how to alleviate the woes created by technical debt, so feel free to pass your thoughts along to me. And if you really want to share your thoughts with us, you can always join us!
