Like a hangover, technical debt is a headache that plagues many IT organizations. Technical debt accumulates when software development decisions aren’t up to recommended or necessary standards when moved into production.
Like financial debt, technical debt may not be a bad thing when used to drive a critical project forward, particularly if the initiative promises some type of immediate value. Unfortunately, technical debt is frequently misused as a compromise that places speed above good practices.
Technical debt is a collection of design or implementation constructs that are expedient in the short term butcreate a context that can make future changes more costly or impossible, says Ipek Ozkaya, technical director of engineering, intelligent software systems, at the Carnegie Mellon University Software Engineering Institute, in an online interview.
Technical debt is often created by well-intended and sometimes justified trade-offs, such as looming deadlines, uncoordinated teams unintentionally developing competing solutions, or even patterns and solutions that were at one time elegant but haven’t aged well, says Deloitte CTO Bill Briggs. “There’s usually a commitment to come back and fix it in the next release or the next budgeting cycle, but priorities shift while the interest from technical debt grows,” he notes in an email interview.
Facing Costs and Delays
For many public and private sector enterprises, paying down technical debt represents a large percentage of their annual technology investment, Briggs says. “As a result, new projects that depend on aging tech have a high probability of delays and ballooning costs.”
Perhaps most ominously, by siphoning funds away from critical cybersecurity updates and initiatives, technical debt can play a significant negative role in breaches and service outages, potentially leading to financial, operational, and reputational risks, Briggs says. Technical debt can also make it hard, sometimes even impossible, to harness and scale promising new technologies. “Transformational impact typically requires emerging tech to be embedded in business process systems, where technical debt is likely to run rampant.”
Regaining Control in Software Ecosystems
There’s no one-size-fits-all approach to controlling technical debt, since the priority and the impact of short-term gains and long-term system, resource, and quality impacts are often context specific, says Ozkaya, co-author of the book “Managing Technical Debt: Reducing Friction in Software Development“. However, teams can get ahead of unintentional technical debt by incorporating modern software development practices and investing in automated quality analysis, unit and regression testing, and continuous integration and deployment tools and practices, she notes.
Technical debt is a reality in today’s software ecosystems, Ozkaya states. “They evolve fast, have to adjust to changing technology, new requirements need to be incorporated, and competition is rough,” she observes. Virtually all organizations have some level of technical debt. “The right question to ask is not whether it’s useful or not, but how it can be continuously and intentionally managed.”
Still, organizations don’t want to find themselves drowning in unintentional technical debt. “Instead, they want to make the right tradeoffs and strategically decide when to accept technical debt and when to resolve it,” Ozkaya says.
A Strategy for Debt Taming
Taking a head-on approach is the most effective way to address technical debt, since it gets to the core of the problem instead of slapping a new coat of paint over it, Briggs says. The first step is for leaders to work with their engineering teams to determine the current state of data management. “From there, they can create a realistic plan of action that factors in their unique strengths and weaknesses, and leaders can then make more strategic decisions around core modernization and preventative measures.”
Managing technical debt requires a long-term view. Leaders must avoid the temptation of thinking that technical debt only applies to legacy or decades old investments, Briggs warns. “Every single technology project has the potential to add to or remove technical debt.” He advises leaders to take a cue from medicine’s Hippocratic Oath: “Do no harm.” In other words, stop piling new debt on top of the old.
Technical debt can be reduced or eliminated by outsourcing, says Nigel Gibbons, a director and senior advisor at cybersecurity advisory firm NCC Group. Focus on what you do best and outsource the rest, he recommends in an email interview. “Cloud computing and managed security services are the panacea for most organizations, offering a freedom from the ball and chain of IT infrastructure.”
Coming to Terms with Tech Debt
Technical debt can be useful when it’s a conscious, short-term trade-off that serves a larger strategic purpose, such as speed, education, or market/first-mover advantage, Gibbons says. “The crucial part is recognizing it as debt, monitoring it, and paying it down before it becomes a more serious liability,” he notes.
Many organizations treat technical debt as something they’re resigned to live with, as inevitable as the laws of physics, Briggs observes. Some leaders vilify technical debt by blaming predecessors for allowing debt to pile up on their watch. Such attitudes are useless, however. “Leaders should be driving conversations to shine a light on the impact, implications, and potential path forward,” he advises.