A recent CAST report concluded that businesses were exposed to massive technical debt that would cost millions of dollars to fix. Just what is technical debt and what can senior managers do to keep their technical debt under control? In this story, CIOs and IT managers will learn from three leaders in the industry who have dealt with technical debt. They will explain what technical debt is and why it occurs, give some real world examples...
and give recommendations for addressing it.
What is technical debt?
Like many terms in software development, there are often variations in definitions as well as multiple terms or phrases used to mean the same thing. IT professionals talk about many kinds of "debt" in software: design debt, code debt and architectural debt, to name a few. Author Chris Sterling, in his book, Managing Software Debt: Building for Inevitable Change, uses the term "software debt" of which he says "technical debt" is a subset. The five types of debt he identifies are: technical, quality, configuration management, design and platform experience.
He says the term "technical debt" is used commonly but he believes technical debt is "focused mainly on the programming aspects of software development. He explains that Ward Cunningham coined the term "technical debt" using "debt" as a metaphor. When we go into debt, we are knowingly putting off "complete payment;" however, at some point that debt needs to be paid off.
Felipe Rubim, systems architect and team lead at Ci&T explains technical debt this way:
Technical debt is an analogy created to easily explain to any software process stakeholder that any poor architectural/design decision taken, for various reasons, is essentially a loan and will incur interest in the future and harm the future potential of the project. Also, every opportunity where the debt is not paid back in full (or not amortized) will make the solution harder to maintain and evolve (and harder to pay the debt back).
What are the common types of technical debt and why do they occur?
There are many reasons teams get into a situation where they’ve incurred debt. Basically, they are sacrificing quality for speed. Often there are pressures from the business to deliver quickly. Because addressing technical debt is not something that can be seen or demoed to the customer, often it is not considered a priority to the business.
Isreal Gat, Agile Practice Director at the Cutter Consortium, says that technical debt is one of the four pillars of the practice, with the other three being Agile, DevOps and software governance. When asked what he believed were the most costly types of technical debt, he answered that the three worst “sins” were: lack of unit test, complexity and duplication.
Rubin mentions these types of technical debt, explaining why they occur:
- Domain knowledge - Not knowing the business domain completely in advance will likely require the architecture/design be changed later in the project, once more light is shed about the new requirements.
- Prudent design decisions - Due to various factors (e.g. time), the team decides to use a framework that is not the best the solution, but that will suit the purpose at that moment. When this decision is made, it’s already known that an update will be needed down the road so new enhancements will not be impacted, but even with this knowledge, the framework is used.
- Sacrificing best software development practices - Not conducting proper design, code review, unit testing and refactoring when the time is needed, again, due to various factors (team skills, timeline, budget, etc).
Enterprise IT Director Sean Rich has dealt with the technical debt associated with legacy code. He gives an example of a simple Web form that can grow into a full-blown major application without the proper processes that would normally occur in development.
He explains that a tight deadline leads to teams building on top of existing architecture to enable new capabilities, resulting in a patchwork of different changes by different people. Over time, these systems need to be replaced.
Real world examples
We know it exists, but how big of a problem is it, really? According to the CAST study, it would take millions of dollars to address technical debt. Is it worth it? I asked our experts if they had any real world examples of technical debt.
Gat answers that he has encountered technical debt issues many times. He offered the example of working with a VC a couple years ago on a portfolio company. "The technical debt there was so high that no new functionality was produced -- the whole development team was 'mortgaged' to bug fixing.”
Rubim responds that Internet Explorer 6 presents a clear example of technical debt, as it lacks standards and has security flaws that require website developers to spend more time developing for IE6 than other browsers. Legacy systems are also likely to experience debt, as functionalities are added to them without the proper time for refactoring/redesign. Furthermore, he explains, “At different levels, all major products that are developed have already accrued (or will accrue) technical debt.”
Advice for IT leaders
A final question for our experts: What advice would you give to managers regarding addressing technical debt?
Overall, it's quite difficult to prevent all the types of technical debt from occurring. In software development, decisions must be taken and weighed against several factors -- which may lead to a technical debt.
The most important advice is to prevent technical debt from increasing by making sure you track it and take advantage of every opportunity to amortize it or pay it in full.
To that point, stakeholders and team members must use System Thinking and understand that the process used in building your software today must allow you to keep a sustained pace as you continue developing the solution in the future.
“It is like flossing teeth. No disaster happens if I do not floss today. Probably nothing much if I do not floss for a week. Neglect for longer periods will probably make me land in the dentist’s chair. Ditto for technical debt - you must refactor the code on an ongoing basis.”
And from Rich:
If I had to pick one thing, I believe the best thing leaders can do is encourage a shift in mindset from a short term game to long term...to move from project management to product management.Too often, an organization's perspective favors short term gain over long term sustainability and that's how debt builds. It's a natural human tendency that leaders need to understand, observe for and steer the organization away from.
Why type of technical debt does your organization deal with? Send your answer to firstname.lastname@example.org.