Technical debt is all but inevitable. In fact, even the headline for this article presumes some level of tech debt in your organization – because unless you work in a magical fantasy land where the code is always pristine and developers never have to make trade-offs, it’s true. Most IT leaders and software engineers will agree with this premise to varying degrees.
“Wherever software is written, technical debt is a reality,” says Mike Duensing, CTO and EVP of engineering at Skuid.
We recently shared tips on explaining technical debt in plain terms that everyone can understand – an important topic because of that reality – and because IT leaders need to be able to teach others in the organization about why properly managing tech debt matters.
[ Before you discuss tech debt with your bosses, customers, or partners, learn how to explain technical debt in plain English. ]
Today, we’re looking at ways to manage your organization's technical debt so that it stays at manageable levels. First, let’s be clear about how it accrues.
What causes technical debt
Technical debt fundamentally accrues when software design and implementation decisions bump up against – or straight-up collide with – business goals and deadlines. This is why it exists in virtually every organization: If you always waited until every last line of code was perfect before you deployed, well, your organization probably wouldn’t be around for long.
“Technical debt occurs when IT teams need to forgo certain development work – [such as] writing clean code, writing concise documentation, or building clean data sources – to hit a particular business deadline,” says Scott Ambler, VP and chief scientist of disciplined agile at Project Management Institute. “It is inevitable and can sometimes make sound business sense, such as when speed-to-market is critical, when resources are limited, or information is incomplete.”
At some point, though, you need to pay that debt down. You’ll also need to keep things in balance: Too much technical debt, just as with financial debt, can become a crushing problem.
“When the business puts too great an emphasis on deadlines, the team often cuts corners to try to meet them,” says Christian Nelson, VP of engineering at Carbon Five. “This might work in the short term, but the growing technical debt will crush productivity before long and require a significant effort to pay down.”
A common technical debt example
Here’s a common scenario, courtesy of Justin Brodley, VP cloud operations & engineering at Ellie Mae and co-host of The Cloud Pod. Let’s say there’s a multi-million-dollar deal on the table, or a new multi-million-dollar revenue stream, but it will require a net-new application development.
“It is a normal by-product of software development: the UI/UX team designs the best interface they can. [Then] the development team looks at it and says it will take six months to build, [but] the product management person needs to ship in three months,” Brodley says. “What can we take out of the product to get the best UI but without the complexity?”
So the dev, product, and UI/UX folks start taking things out to reduce complexity, but they’re still short of that three-month timeline. The next question, naturally: What else can we take out?
“Well, you can remove things like developing automated tests and error handling, [or] make it vertically scale instead of horizontally scale,” Brodley says. Then you reach some version of this decision: “We’ll fix that in the next sprint.”
That’s technical debt, and it’s not unlike how a homeowner who suddenly needs a new air-conditioning unit in the middle of a sweltering summer might say: “We’ll pay for this over the next 12 months instead of all right now.”
[ Learn the do's and don’ts of cloud migration: Get the free eBook, Hybrid Cloud for Dummies. ]
Is technical debt bad?
This isn’t a bad thing, Brodley and others note. Technical debt becomes a bad thing when you don’t actually follow through on the “we’ll fix this later” promise.
These kinds of tradeoffs aren’t the only cause of technical debt. Most technologies are eternally becoming outdated; deferring maintenance or upgrades, for example, is also a source of debt.
Not matching the right people to the project or job also drives technical debt. “Sometimes teams of mostly junior developers are expected to build complex software without the necessary support – [such as] mentoring and guidance,” Nelson says. “It’s unfair to expect someone with less than a few years of experience to exercise the judgment of a senior developer. It’s no surprise that projects like this can accumulate tech debt really quickly.”
Nelson adds that technical debt shouldn’t be thought of as some heinous crime of software development; it most often accrues for good (or at least understandable) reasons.
“It’s important to point out that technical debt isn’t really the result of deliberate malfeasance, and rarely incompetence,” Nelson says. “Lack of shared values, aggressive business deadlines, and unrealistic expectations are the primary culprits.”
Now let’s examine four pieces of advice to minimize your ongoing technical debt:
