There’s an adage that came into being in the early 2000s that said, “Buy the computer you need for tomorrow, not today.” The saying exists because consumers tended to purchase the cheapest computer they could buy, only to find it quickly became somewhat obsolete. That computer would have to be replaced much sooner than preferred because software is always evolving and demanding more and more from the hardware on which it runs.
The same applies to companies who pay for the development of software projects. Company A reaches out to an outsourced software development firm (be it onshore, nearshore, or offshore) for a new project. When the third-party comes back with a quote, the company might opt to go with an easier solution to get the cost down, or they insist the developers meet nearly impossible deadlines (which can result in less-than-ideal code). The project gets the green light and moves forward.
Soon after the project is deployed, it becomes obvious that the product is too limited, inefficient, or incapable of scaling to meet the needs of rising demands. The company that opted for the cheaper solution will find numerous problems that will eventually arise.
Or, maybe your company has legacy code that runs a good portion of the backend. That legacy code is not only starting to show its age, it’s making it nearly impossible to expand services to allow the business to employ newer technologies (such as cloud and containers). Those in charge of making these types of decisions opt to continue holding off on moving away from that legacy system. Or they panic and insist the development team roll out a replacement so quickly they don’t have time to bake in all the required features.
What do you do? You incur technical debt.
What is technical debt?
Technical debt is when your developers must take action or delay certain work on a development project to meet a delivery deadline. Those developers know the costs of such actions and delays and understand they (or the company) will be “paying for” them later on in the development lifecycle.
The longer your company holds back on paying off technical debt, the harder it will be to rectify any given situation. This “interest” is similar to failing to pay the monetary debt on time. And the accumulation of technical debt makes it harder and harder to address the problem at hand.
Technical debt can be incurred in 3 primary areas:
- Application (the software)
- Infrastructure (operating systems and environments)
- Architecture (hardware)
There are also reasons why your company might be willing to incur technical debt. One of the most widespread reasons is when a delivery deadline is more important than the completeness or cleanliness of the delivered code. If your company would lose money because of a delay, the incurring of technical debt might be acceptable.
Of course, after you incur in technical debt, you have to figure out how to pay it off sooner rather than later. How can you do that? Let’s examine some of the ways.
1. Locate the compromises
The first thing you must do is head back to the project’s drawing board to discover the compromises you made and that led to the incurred debt. Were the compromises that you opted to go with JavaScript instead of Java to expedite the rollout? Or maybe you opted to forego certain features you wanted, to get the software deployed at an earlier date. Your technical debt might have also been incurred by not rolling in security throughout the development lifecycle. That’s a particular kind of debt you’ll be paying back for quite some time.
You might have also purchased either infrastructure (such as a cloud host) or architecture (such as a server) that is only capable of handling your current demand, but not the demand you expect in the near future. Those are compromises of cost, a form of technical debt that can be easily remedied by purchasing more cloud resources or more powerful hardware.
When you locate the initial compromises, you must then decide if it’s possible to pay off the technical debt and how quickly you can do so. Is it possible for your in-house developers to address the shortcomings of the project in logical and efficient ways? And can the technical debt be mitigated easily, or will the entire project need to be scrapped?
2. Make security a priority
You must address the technical debt incurred by security (or a lack thereof). Everyone involved needs to examine the project to find out how they can implement security and inject it at all stages of the project (even with it already rolled out).
You might also consider creating a new team dedicated to owning the security of the development lifecycle. That team would be responsible for ensuring security best practices are applied at every stage of the project. And even if a current project can’t benefit from the new team’s existence, all other projects moving forward can.
3. Don’t ignore your developers
Developers are your best route to paying off technical debt. They know the project, inside and out, and can tell you exactly where you incurred in debt within the project lifecycle. You might be so inclined to not take heed of their warnings or advice, and prefer to give those in management positions more credence. That’s a mistake. By not listening to your developers, your technical debt will increase exponentially.
To this end, you should have regular meetings with your developers and give them agency to affect change. Once you’ve empowered your developers, they will be able to make it possible for your company to effectively pay down technical debt. Ignore their advice and that debt will continue to pile on.
4. Include technical debt in your strategy
The worst thing you can do is ignore technical debt. It won’t go away by itself. In fact, the longer you ignore technical debt, the more debt you’ll have and the harder it will be to pay down. Because of that, you need to include technical debt in your company and development strategy.
To be more specific, you should include technical debt in every step of your development lifecycle. When you’ve done that, you’ll be much better prepared to understand exactly when and where the debt occurred and how best to pay it back.
When you integrate technical debt into your development lifecycle, you will never be caught off guard and ill-prepared when the time comes to pay that technical debt down. As your project moves along the lifecycle, make sure to track all possible maintenance costs so you can prioritize what debt should be paid off first. For example, if one aspect of a project will require significant development hours to pay off, that should be a priority. Make sure to bake this into the lifecycle.
5. Live with it
Another means of paying off technical debt might not be the most desirable – but at some point, it could become a necessary means to an obvious end. Say your developers had to forego a particular feature in a piece of software, simply to meet the delivery deadline. If the software functions reasonably well, you might decide to live with the functionality it offers and forget about the feature you left out.
When you take this route, you can always gain that extra functionality in v2 of the software, or maybe from another project. Either way, if you waive that feature off, the debt is paid in full.
Conclusion
There are many ways to incur technical debt as ways to pay it off. The most important thing, however, is that you do not ignore technical debt and make sure to pay it off before too much “interest” accrues. If you find yourself buried in technical debt, you (and your company) will always feel trapped behind software that doesn’t function as desired, isn’t as secure as necessary, or loses your business money.
