This article is more than 1 year old

Software shortcuts: Pay down your tech debt. It's time to fix a price

Rushing to ship won't get you to the other side

Technical debt: we probably create it every day. It happens when you do things that might get you closer to goal now, but which create problems that you’ll have to pay for later.

The concept “technical debt” in software design and development comes from Agile development guru Ward Cunningham. He described what happens when you rush to ship software without applying what you’ve learned about the problem you’re trying to solve.

If you don’t refactor your software to reflect your understanding as it evolves, the software will fall out of step with your needs.

The interest payment on that debt is the extra effort that you must put into future progress because of earlier design choices. The longer you leave it, the higher those payments get. Eventually, it might slow you down to the point where you can’t ship new features or innovate, potentially costing your business money or customers, and your developers their hair.

Technical debt is slowing people down at just the point that they’re supposed to be powering ahead. Companies have several transformational technologies to choose from, such as mobile computing, cloud, social, and AI, which could take their businesses to new heights. Out-of-date systems and software is getting in the way.

A survey of 463 IT pros published in January found nine out of 10 struggling with technical debt, saying it was delaying software delivery. Nearly three in four said that it got in the way of how quickly they can deliver new features according to the poll by Appian.

OK, but how does that look in the real world?

Scotland’s NHS was recently hauled over the coals by the Scottish Parliament’s Health and Sport Committee for its lack of innovation in digital healthcare. Among the problems identified were outmoded systems that couldn’t be made to work together, partly the result of years of programming decisions.

It’s classic legacy and a clear example of decisions taken early on during the development and coding process coming back to bite you later – much later in this case. It’s a variant of technical debt.

Like any debt, technical debt must be paid down. What happens when you don’t? In IT you inevitably reach the point where a system becomes too complicated and so expensive to maintain that it falls out of date and eventually out of step with your business. ERP systems, which are the beating heart of many larger organisations, are a good example of this – systems that have run the gamut of the debate over whether ‘tis best to install-out-of-the-box or to customise. The latter is obviously a route fraught with the risk of technical debt.

In its 2017 report, "Avoiding Technical Bankruptcy in Legacy Systems", analyst group Computer Economics reckoned ERP systems that have gone five to nine years since their last install or upgrade are in danger of falling into technical bankruptcy, while those left untouched for a decade are probably already there. It reckoned one in five systems are either beyond hope, or close to it.

Brian Murray, head of service development at IT services consultancy ECS, says that technical debt can be crippling for businesses. "IT functions can’t get their service agility and service movement up to date fast enough because they’re being held back by the anchors of the various pieces of technical debt," he says. "What comes with that is a culture of not progressing, which is completely contrary to the whole nature of IT."

Sometimes you need a mortgage

Sounds terrible, but not all technical debt is bad. Sometimes it can be a tool to help you meet your objectives. You take on a mortgage because it’s a structured debt that gets you a place to live now, with a long-term but manageable payment.

On the other hand, you don’t burn through your credit card limits eating out at expensive restaurants because you can’t be bothered to cook at home, without any thought for the interest you’ll be paying later.

Similarly, Martin Fowler, a co-signatory of the Agile Manifesto alongside Cunningham, divides technical debt into prudent and reckless debt. The former is debt you can take on because the interest payments are small, and the benefit of the debt is high. Reckless is the inverse: a high level of debt that with a high material impact.

What kinds of material impacts might those be? Apptio is a company that sells software to help companies manage their technology investments over time. With that in mind, executive vice president of products and engineering Theo Beack spends a lot of time thinking about the kinds of technical debt that crop up and the cost of the payments in time and money.

One example of technical debt lies in performance, he says. "Let's say we have a fantastic solution, but at some point we hit a certain threshold with a customer and hit a performance issue. It’s a consequence of how the underlying technology processes certain types of volume, or a complexity in the schema."

The company may not have even realised that it had a problem, and it may not be because of deliberate corner-cutting in the past. Nevertheless, it faces a decision: should it spend time and money fixing the problem, or should it kick the can down the road?

The answer isn’t always obvious, because performance issues like that can be complex and expensive to fix, he warns: "It usually takes quite a bit of time, it involves quite a few touchpoints in your technology, and it’s expensive to replace."

Beack categorises other kinds of technical debt, such as integration. There are many integration points between a company's own software and the third-party software products that it talks to. Maintaining those integrations can be difficult. If you don't stay current, then he warns you could send yourself into the red technology-wise, as you struggle to play catch-up.

Sometimes, your technical debt may come from other people. Consider upstream open-source software that is not managed by a vendor under contract. You may use an open source library to help build your products. If a new version is released that is not backwards-compatible with the APIs you’re using, then you will find yourself having to find a solution. The same applies to open source libraries that are deprecated. “The moment that happens you suffer from technical debt,” he says.

Slow down, Speedy Gonzales

Some experts interpret technical debt more widely than decisions about software architecture. Murray cites the example of wanting to move to a new application. You may not be able to, because you’re still running an operating system that doesn’t support it. Upgrading your OS will involve a lot of stakeholders and take a lot of time. The longer you delay that action, the further behind you fall. Perhaps you could just forklift the whole tangled mess into the cloud and have someone else worry about it?

Slow down, says Richard Blanford, founder and managing director of managed cloud services and IT consulting firm Fordway Solutions. SaaS and PaaS may work, providing you with a black-box service with a level of configuration that you can control, without getting into the infrastructural detail.

“As soon as you start going below that, you have a load of standard IT operations stuff which IT ops guys have been dealing with for years, but designed to somebody else’s design and architectural model that may not fit what your legacy needs,” he warns.

Martin Percival, principal solutions architect at Red Hat, warns that lock-in can also make cloud-based services the very definition of an easy decision now that costs you dearly later. “If you choose to implement everything on Amazon, then there's a technical debt for you, because you can't easily move it to Azure,” he says.

While many talk about technical debt from a broader systems perspective, a lot of the discussion goes back to software, especially when you try to measure it. Beack describes it in terms of software defects. Measuring the number of defects per thousand lines of code is a long-established metric for looking at software flaws, although he reminds us that this simple ordinal scale won’t be enough – it makes sense to look at the severity of the bugs too. Measuring technical debt may make it easier to manage, or at least give you a starting point to determine which defects matter most to a business trying to accomplish its goals. Then, ‘paying down’ that debt by targeting it becomes a budgetary decision.

Beack breaks down R&D investments into several categories, each extending over three-year periods. These categories include maintaining technology, investing in closing feature gaps, entirely new internal innovations, and meeting customer commitments (either internal or external).

Some of these are non-negotiable. A company must hit its customer commitments and maintenance goals, and the business will understand those. “Sometimes the technical debt gets short-changed because the business doesn’t understand what it means and why it’s important to pay down,” he says.

The irony is that technical debt will affect all those other categories, making it more difficult for a company to reach its goals there. His team quantifies the technical debt and looks at how it affects those other areas. Then he quantifies the outcome from paying down the technical debt. Will it enable the company to scale a certain function that’s important to growth, or develop the systems that will enable it to attack a new market segment?

Just as you might make a case for paying down a financial loan earlier or capitalising on cheap money and investing your surplus elsewhere, so he makes a business case for how much technical debt to pay down, and which bits of it to focus on.

DevOps and continuous integration can help here, says Percival. These concepts bring – or should bring - development and operations closer together, automating the creation and deployment of software so that technology teams can iterate through software lifecycles more quickly.

“Agile development makes the idea of rapid failure much more acceptable because you’re looking at continuous improvement as a way to fail fast and fix it, and get closer to what you’re about to deliver,” he explains.

Automation plays a big part in speeding up your technical debt payments, according to Beack. “Your construction of the testing environment is automated, which means that you can run end-to-end tests and regression testing in an automated fashion,” he says.

“You test iteratively throughout the development cycle. What that allows us to do is reach a level of scale where you find defects and performance and integration issues in real time, and you’re able to fix it in real time.” Percival adds that involving business stakeholders in these discussions early on can help to pay down the right technical debt more quickly.

“Let’s not wait till we’re 10 spins into the cycle,” he continues. “Let’s make sure the dev team, the ops team and the biz team are in the room saying this is what we need to build on day one.”

By mixing all three teams, companies can address not only the software side of technical debt, but the infrastructural side and the business side too. At the end of the day, treat technical debt like financial debt: carry a little where it makes sense but use it in a calculated way – such as in the case of a mortgage. Letting it run away with you because you haven’t kept your eye on it can leave your IT strategy veering off-course or grinding to a halt. ®

We'll be covering DevOps at our Continuous Lifecycle London 2018 event. Full details right here.

More about


Send us news

Other stories you might like