As far as IT topics go, technical debt offers a built-in advantage when it comes to defining and understanding it: The name is more self-explanatory than most tech terms.
“Conceptually, technical debt is similar to financial debt,” says Mike Duensing, CTO and EVP Engineering at Skuid. “For the borrower, it is more important to purchase an item and have it in hand now than it is to save up the funds to purchase in all-cash.”
We take on technical debt for reasons similar to why we take on financial debt: We need something now (or very soon) that we don’t have the “cash” to pay for in full. So we borrow to get what we need. With software, this generally means making coding or design decisions that are sub-optimal – or that we know will need to be addressed and updated in the future – in order to get what we want or need into production sooner.
[ Learn the do's and don’ts of cloud migration: Get the free eBook, Hybrid Cloud for Dummies. ]
“Technical debt – or code debt – is the consequence of software development decisions that result in prioritizing speed or release over the [most] well-designed code,” Duensing says. “It is often the result of using quick fixes and patches rather than full-scale solutions.”
Some amount of technical debt is virtually inevitable, Duensing and other software pros point out. Leaders and teams must strike a balance between business goals and a litany of design and implementation decisions; a developer or team that never makes anything other than the most optimal choices in their code is going to be hard-pressed to ship with any kind of regularity or speed.
So the intrinsic financial analogy comes into play again: We must use debt responsibly. We take on debt understanding that it will need to be repaid, for starters. And continuously piling on new debt without ever reducing your existing balances is going to cause all manner of problems – if not actual ruin – down the road.
For many IT leaders, the big picture goal is to move money away from legacy tools and processes over to more innovative work. Other related goals may include a better user experience, say with an updated SaaS application versus a legacy one; a more agile IT infrastructure; and cost savings. One pain point is that legacy systems and processes tied up with technical debt often involve a complicated web of interdependencies, of both tools and policies.
As you discuss your organization’s technical debt situation - and possible changes to it - with a variety of audiences, it’s important to be able to articulate these issues in plain terms. So let’s delve into some expert advice on doing just that.
Technical debt: 3 definitions
Part of responsible technical debt use lies in a straightforward understanding of the concept and how it manifests. Let’s arm you with some other definitions of technical debt, in addition to Duensing’s above.
“Technical debt is the result of the design or implementation decisions you make and how those decisions age over time if they aren’t incrementally adjusted or improved. The longer you hold fast to those designs and implementations without incremental adjustments or improvements, the larger the debt, or effort, becomes to make those needed changes.” –Justin Stone, senior director of secure DevOps platforms at Liberty Mutual Insurance
“Technical debt is when the implementation – the code – for a product becomes unnecessarily complex, inconsistent, or otherwise difficult to understand. While there is no perfect code, code that contains technical debt [moves] farther [away] from a good solution for the problem it solves. The more debt, the farther the code misses the target. Technical debt makes it harder to understand what the code does, which makes it harder to build upon, and ultimately results in poor productivity and defects in the product.” –Christian Nelson, VP of engineering at Carbon Five
“Technical debt is the cost of technical decisions that are made for the immediacy, simplicity, or [budget] that, while easy today, will slow you down or increase your operational costs/risks [over time]. Most often it’s related to technical products, but can be found in most business processes and use cases. Many times this technical debt can turn into ‘human spackle,’ where knowledge workers do repetitive tasks that could be automated.” –Justin Brodley, VP cloud operations & engineering at Ellie Mae and co-host of The Cloud Pod
How to explain technical debt to non-technical people: The car loan analogy
Some technology topics prove more difficult to explain to folks outside of IT. (Think service meshes, or serverless, for example.)
Again, this is a “beauty” of technical debt. The term itself is already doing some of the work for you. Which is good, because technical debt can have a broad impact throughout your organization – think of the “human spackle” Brodley describes above – and its ability to build new things, effectively serve customers, and more.
“Technical debt is no different than debt in your day-to-day life,” Stone says. “You can take on debt to have something of value you need now and worry about that debt later, or you can delay what you need now to save and take on less debt for that same thing of value.”
Some things are more of a necessity than others: A car to get to and from work, for example. Many people can’t just decide to postpone that purchase for months or years to save up the necessary cash: So they take out a car loan. That means they’re paying extra for the car over time, but they get what they need now.
The same principle applies when making development decisions that will impact a codebase over time. (Brodley notes that even if your vehicle is paid in full, you’ve still got maintenance to consider: Ignoring it will likely cause more expensive problems later, including downtime for major repairs.)
“There are always tradeoffs for when you want it versus when you need it,” Stone says. “And just like with personal debt, the longer it takes to pay off technical debt, the more interest and cost accumulate. Time may show that the initial decision wasn’t as good as you once thought because of the mounting costs and interest payments.”
Another analogy: Meet the Franken-car
Technical debt isn’t just a matter of short-term and long-term costs, either. It can also affect system performance itself. Let’s continue to use your daily vehicle as a metaphor, except the car itself is a proxy for one of your applications. Actually, in this case, imagine two cars.
“The first [is a] well-designed, high-end model from whatever brand you like the best,” Nelson says. It’s well-designed on the outside and runs beautifully and reliably on the inside. Everything works as expected, has a purpose, and doesn’t surprise you.”
That “car” is a software team’s goal: Your application works as expected. It fulfills its purpose well without surprise breakdowns or costs.
The second car, however, is not quite the same – even if it functionally resembles a car.
“It gets you from A to B, most of the time, and it has most of the same features as the first car. This car is different though,” Nelson says. “First, it’s obviously not a car, but really a retrofitted tractor, and before that, it looks like it has some parts that you would see on a boat. It’s both clear this vehicle has morphed over time from solving one problem to another related problem, and the people who made it didn’t have the time or skills to remove signs of its previous incarnations. When switching on the turn signal, the horn sometimes honks, too. Rolling down a window pops open the trunk when you’re unlucky. And you still haven’t found the emergency brake.”
This Franken-car is what you drive when you have no viable alternative. Yes, it should get you from A to B, but don’t expect a pleasant ride. This, Nelson says, is what working with a codebase saddled with excessive technical debt is like.
Remember, technical debt doesn’t apply just to technology: It applies to processes as well. That’s important to remind people of, as you evaluate which tech debt has to go, and which you can live with for now.
“When thinking about modernization, don’t focus solely on modernizing the technology,” says David Egts, chief technologist, North America public sector for Red Hat. “Think about modernizing the people and processes too. If you only modernize the technology with a faster computer, you may not be addressing underlying reliability and scalability issues forcing the modernization effort in the first place. These issues can be addressed by reskilling the workforce to write cloud-native applications, as well as using agile and DevSecOps practices.”
Now let’s delve into explaining why people should care about technical debt: What problems accumulate over time?
