Calculating Technical Debt Can Focus Modernization Efforts
By Tobias Naegele
November 14, 2017
Share this page:
Your agency’s legacy computer systems can be a lot like your family minivan: Keep up the required maintenance and it can keep driving for years. Skimp on oil changes and ignore warning lights, however, and you’re living on borrowed time.
For information technology systems, unfunded maintenance – what developers call technical debt – accumulates rapidly. Each line of code builds on the rest, and when some of that code isn’t up to snuff it has implications for everything that follows. Ignoring a problem might save money now, but could cost a bundle later – especially if it leads to a system failure or breach.
The concept of technical debt has been around since computer scientist Ward Cunningham coined the term in 1992 as a means of explaining the future costs of fixing known software problems. More recently, it’s become popular among agile programmers, whose rapid cycle times demand short-term tradeoffs in order to meet near-term deadlines. Yet until recently it’s been seen more as metaphor than measure.
Now that’s changing.
“The industrial view is that anything I’ve got to spend money to fix – that constitutes corrective maintenance – really is a technical debt,” explains Bill Curtis, executive director of the Consortium for IT Software Quality (CISQ), a non-profit organization dedicated to improving software quality while reducing cost and risk. “If I’ve got a suboptimal design and it’s taking more cycles to process, then I’ve got performance issues that I’m paying for – and if that’s in the cloud, I may be paying a lot. And if my programmers are slow in making changes because the original code is kind of messy, well, that’s interest too. It’s costing us extra money and taking extra time to do maintenance and enhancement work because of things in the code we haven’t fixed.”
CISQ has proposed an industry standard for defining and measuring technical debt by analyzing software code and identifying potential defects. The number of hours needed to fix those defects, multiplied by developers’ fully loaded hourly rate equals the principal portion of a firm’s technical debt. The interest portion of the debt is more complicated, encompassing a number of additional factors.
The standard is now under review at the standards-setting Object Management Group, and Curtis expects approval in December. Once adopted, the standard can be incorporated into analysis and other tools, providing a common, uniform means of calculating technical debt.
Defining a uniform measure has been a dream for years. “People began to realize they were making quick, suboptimal decisions to get software built and delivered in short cycles, and they knew they’d have to go back and fix it,” Curtis says.
If they could instead figure out the economic impact of these decisions before they were implemented, it would have huge implications on long-term quality as well as the bottom line.
Ipek Ozkaya, principal researcher and deputy manager in the software architecture practice at Carnegie Mellon University’s Software Engineering Institute – a federally funded research and development center – says the concept may not be as well understood in government, but the issues are just as pressing, if not more so.
“Government cannot move as quickly as industry,” she says. “So they have to live with the consequences much longer, especially in terms of cost and resources spent.”
The Elements of Technical Debt
Technical debt may be best viewed by breaking it down into several components, Curtis says:
- Principal – future cost of fixing known structural weaknesses, flaws or inefficiencies
- Interest – continuing costs directly attributable to the principal debt, such as: excess programming time, poor performance or excessive server costs due to inefficient code
- Risk and liability – potential costs that could stem from issues waiting to be fixed, including system outages and security breaches
- Opportunity costs – missed or delayed opportunities because of time and resources focused on working around or paying down technical debt
Human factors, such as the lost institutional memory resulting from excessive staff turnover or the lack of good documentation, can also contribute to the debt. If it takes more time to do the work, the debt grows.
For program managers, system owners, chief information officers or even agency heads, recognizing and tracking each of these components helps translate developers’ technical challenges into strategic factors that can be managed, balanced and prioritized.
Detecting these problems is getting simpler. Static analysis software tools can scan and identify most flaws automatically. But taking those reports and calculating a technical debt figure is another matter. Several software analysis tools are now on the market, such as those from Cast Software or SonarQube, which include technical debt calculators among their system features. But without standards to build on, those estimates can be all over the place.
The CISQ effort, built on surveys of technical managers from both the customer and supplier side of the development equation, aims to establish a baseline for the time factors involved with fixing a range of known defects that can affect security, maintainability and adherence to architectural design standards.
“Code quality is important, process quality is important,” Ozkaya says. “But … it’s really about trying to figure out those architectural aspects of the systems that require significant refactoring, re-architecting, sometimes even shutting down the system [and replacing it], as may happen in a lot of modernization challenges.” This, she says, is where technical debt is most valuable most critical, providing a detailed understanding not only of what a system owner has now, but what it will take to get it to a sustainable state later.
“It comes down to ensuring agile delivery teams understand the vision of the product they’re building,” says Matthew Zach, director of software engineering at General Dynamics Information Technology’s Health Solutions. “The ability to decompose big projects into a roadmap of smaller components that can be delivered in an incremental manner requires skill in both software architecture and business acumen. Building a technically great solution that no one uses doesn’t benefit anyone. Likewise, if an agile team delivers needed functionality in a rapid fashion but without a strong design, the product will suffer in the long run. Incremental design and incremental delivery require a high amount of discipline.”
Still, it’s one thing to understand the concept of technical debt; it’s another to measure it. “If you can’t quantify it,” Ozkaya says, “what’s the point?”
Curtis agrees: “Management wants an understanding of what their future maintenance costs will be and which of their applications have the most technical debt, because that they will need to allocate more resources there. And [they want to know] how much technical debt I will need to remove before I’m at a sustainable level.”
These challenges hit customers in every sector, from banks to internet giants to government agencies. Those relying solely on in-house developers can rally around specific tools and approaches to their use, but for government customers – where outside developers are the norm – that’s not the case.
One of the challenges in government is the number of players, notes Marc Jones, North American vice president for public sector at Cast Software. “Vendor A writes the software, so he’s concerned with functionality, then the sustainment contractors come on not knowing what technical debt is already accumulated,” he says. “And government is not in the position to tell them.”
Worse, if the vendors and the government customer all use different metrics to calculate that debt, no one will be able to agree on the scale of the challenge, let alone how to manage it. “The definitions need to be something both sides of the buy-sell equation can agree on,” Jones says.
Once a standard is set, technical debt can become a powerful management tool. Consider an agency with multiple case management solutions. Maintaining multiple systems is costly and narrowing to a single solution makes sense. Each system has its champions and each likely has built up a certain amount of technical debt over the years. Choosing which one to keep and which to jettison might typically involve internal debate and emotions built up around personal preferences. By analyzing each system’s code and calculating technical debt, however, managers can turn an emotional debate into an economic choice.
Establishing technical debt as a performance metric in IT contracts is also beneficial. Contracting officers can require technical debt be monitored and reported, giving program managers insights into the quality of the software under development, and also the impact of decisions – whether on the part of either party – on long-term maintainability, sustainability, security and cost. That’s valuable to both sides and helps everyone understand how design decisions, modifications and requirements can impact a program over the long haul, as well as at a given point in time.
“To get that into a contract is not the status quo,” Jones says. “Quality is hard to put in. This really is a call to leadership.” By focusing on the issue at the contract level, he says, “Agencies can communicate to developers that technically acceptable now includes a minimum of quality and security. Today, security is seen as a must, while quality is perceived as nice to have. But the reality is that you can’t secure bad code. Security is an element of quality, not the other way around.”
Adopting a technical debt metric with periodic reporting ensures that everyone – developers and managers, contractors and customers – share a window on progress. In an agile development process, that means every third or fourth sprint can be focused on fixing problems and retiring technical debt in order to ensure that the debt never reaches an unmanageable level. Alternatively, GDIT’s Zach says developers may also aim to retire a certain amount of technical debt on each successive sprint. “If technical debt can take up between 10 and 20 percent of every sprint scope,” he says, “that slow trickle of ‘debt payments’ will help to avoid having to invest large spikes of work later just to pay down principal.”
For legacy systems, establishing a baseline and then working to reduce known technical debt is also valuable, especially in trying to decide whether it makes sense to keep that system, adapt it to cloud or abandon it in favor of another option.
“Although we modernize line by line, we don’t necessarily make decisions line by line,” says Ozkaya. By aggregating the effect of those line-by-line changes, managers gain a clearer view of the impact each individual decision has on the long-term health of a system. It’s not that going into debt for the right reasons doesn’t make sense, because it can. “Borrowing money to buy a house is a good thing,” Ozkaya says. “But borrowing too much can get you in trouble.”
It’s the same way with technical debt. Accepting imperfect code is reasonable as long as you have a plan to go back and fix it quickly. Choosing not to do so, though, is like paying just the minimum on your credit card bill. The debt keeps growing and can quickly get out of control.
“The impacts of technical debt are unavoidable,” Zach says. “But what you do about it is a matter of choice. Managed properly, it helps you prioritize decisions and extend the longevity of your product or system. Quantifying the quality of a given code base is a powerful way to improve that prioritization. From there, real business decisions can be made.”