How to Get Ahead by Reducing Technical Debt in 2020
By: Ernest Sampera on September 24, 2019
As an organization grows, it must constantly weigh short term needs against transformative long term goals. Sometimes, dealing with an immediate problem sets off a series of consequences that can cause significant difficulties in the future. Nowhere is this more evident in the world of computer engineering and software development than in the concept of technical debt.
Definition of Technical Debt
Originally coined by the famed programmer Ward Cunningham, technical debt measures the consequences of using shortcuts or easy-to-implement solutions instead of applying a better long-term solution during any computer engineering or software development process. The concept works as a metaphor, comparing the additional coding required to fix bugs or incompatibilities resulting from these shortcuts to paying the interest on financial debt over time.
Also known as “design debt,” technical debt is usually characterized as something to avoid, but there are many instances in which it can’t be avoided. The problem with technical debt, much like financial debt, is that refusing to pay it off promptly makes it even harder to manage. Bugs and other issues associated with technical debt have a way of compounding just like interest on a loan, increasing the amount of time and effort an IT or development team has to spend managing a system or getting it ready to ship.
Technical Debt Examples
To understand how technical debt works, a simple example may be instructive. Imagine a software development team using scrum methodology to build a new mobile application. In the early phase of the coding process, the team may be struggling to make a core function work the way it’s intended. While the team could probably write custom code to accomplish that goal, doing so would take an additional two weeks and the first iteration of the program needs to be working in a few days. To meet the deadline, they throw together a “quick and dirty” solution that works almost as good.
The decision to take this shortcut creates technical debt. While the solution works, it isn’t ideal. It meets the immediate need to deliver something on deadline, but it will create additional problems in the future because the rest of the development process will have to accommodate that suboptimal solution in some way.
Here is where technical debt becomes dangerous. Ideally, now that the deadline has been met, the team could devote resources to building the ideal solution over the next two weeks before moving on to the next stage of the project. But the pressure and cost-benefit analysis of agile development could make that impossible because the team has to start building additional features into the application in order to meet their next deadline. Suddenly, they’re writing code to accommodate the imperfect workaround they’ve already built into the program, which forces them to create new workarounds just to make sure everything works as intended. The technical debt of the project quickly spirals out of control from there, creating a hodge-podge of a program that may never be able to deliver on the original goals of the project. In a worst-case scenario, the accumulation of bugs and inefficiencies may force the team to start over from scratch.
How to Measure Technical Debt
Technical debt is typically measured in time using a calculation called technical debt ratio (TDR). This calculation compares the amount of time it will take to fix a system (eg: paying off the debt) to the amount of time it took to build the system in the first place. Obviously, most organizations strive to maintain a low ratio of remediation cost to development cost, since a high TDR score indicates an ongoing problem with technical debt. A TDR score of equal to or less than five percent is generally considered tolerable.
How to Reduce Technical Debt in 2020
The first step to fixing any problem is understanding how it happened in the first place. When it comes to software development and network design, that process should begin with documentation. When an IT department or development team doesn’t do a good job of documenting changes to a system, it can be very difficult to work backwards to trace a known bug to its source. Creating an ongoing record of changes and known issues is especially important when it comes to legacy systems or applications moving into new environments.
Create a Clear Definition of Done
During the development process, it can be tempting to view coding and testing as two separate steps. Unfortunately, removing successful testing from the definition of “done” on any kind of project is a recipe for incurring more technical debt. When a system or program can be presented as finished and ready to go without any form of comprehensive testing, all sorts of bugs and incompatibilities have the opportunity to fester and create additional problems. There’s also a good chance that testing will not be thoroughly implemented once people begin to view the project as being “done” already.
Automating the testing process can be immensely helpful in reducing technical debt. Setting up manual testing for any system can be incredibly inefficient, both in terms of time spent and the results it produces. Automated testing subjects code and configurations to far more rigorous scrutiny and is more likely to produce replicable results. While setting up automated testing can be time-consuming, the benefits of that up-front investment can significantly reduce the possibility of technical debt in the future, which saves both time and money in the long run.
Today’s systems and applications undergo frequent updates and patches to add new functionality and address longstanding issues. Every round of changes, however, creates an opportunity for more technical debt to accrue. As organizations move their IT infrastructure from on-premises solutions to colocation data centers and cloud deployments, various workarounds are often required to make those systems functions in environments they weren’t originally designed to accommodate. Setting aside time to refactor existing systems on a regular basis in order to streamline code and optimize performance can help to pay down technical debt incrementally.
By taking a proactive approach to minimizing the potential for technical debt and addressing it as it accrues, organizations can avoid situations in which short term solutions come back to undermine their long term goals. This can be incredibly important for growing companies as they transition to more complex IT solutions. Reducing technical debt can also help make data center migrations much smoother. Finding ways to manage technical debt can often prove just as valuable as managing financial debt when it comes to scaling a business successfully.
About Ernest Sampera
Ernie Sampera is the Chief Marketing Officer at vXchnge. Ernie is responsible for product marketing, external & corporate communications and business development.