In our series, Drowning in Technical Debt, we’re digging into the commonly used but often misunderstood phrase “technical debt”, with a mission to help more organizations identify it and work toward a more manageable amount of it. For this first post, we’re defining technical debt and looking at how it can creep into organizations.
Do you see your development team working hard, but still not delivering the value they’re capable of? Do you find yourself saying, “Things weren’t always like this,” implying the problem has grown worse over time? Do you regularly hear, “We can’t do that yet, because that part of the system will break if we change it”? Your organization’s total technical debt could be the culprit of all of these pain points, and others that you’re not even aware of yet.
What Is Technical Debt?
Technical debt is a metaphor designed to help us understand where we’re borrowing development time today, only to repay it in the future. Ward Cunningham, one of the co-authors of the Manifesto for Agile Software Development, first coined the phrase in 1992:
“Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite… The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.”
In 2009, Cunningham went even further to address a common misinterpretation of technical debt as motivation for refactoring. “The ability to pay back debt,” he said, “…depends upon you writing code that is clean enough to be able to refactor as you come to understand your problem.”
How Our Organizations Accrue Technical Debt
Among the experienced Agilists at 3Cloud, we’ve seen the full spectrum of technical debt across healthcare, insurance, financial services, and more. Even across these diverse sectors, we often see companies building up their technical debt in three ways.
1. A Strategic Decision
As with financial debt, sometimes you need to borrow from the future to realize a benefit today. Used strategically, technical debt is a tool that can help you get to market fast. For example, say your development team gives you two options: one that gets value out the door in two weeks with a solution that they know will likely cause performance issues down the road, and one that delivers the same value in two months but also introduces new architecture to support long–term scalability throughout the system. Choosing the two-week option could allow you to deliver a small scope quickly, while still creating a good end user experience. However, it also means you’ll consciously bake a known performance problem into the product, which your team will have to eventually deal with.
You also might decide to accept technical debt when you’re sunsetting an application. You don’t need to invest in the long term when you know you’ll be migrating to a new platform.
2. Learning Exploration
When technical debt is accrued as part of learning exploration, the objective is to learn how not to deliver and forget. This happens when a team doesn’t know enough to make a technically excellent decision, because they’re creating something innovative and are working in a new space. Sometimes, a spike turns into production code.
For example, imagine your team has been tasked with creating a single sign–on experience for users. Since no one on the team has expertise in this area, they decide to roll their own provider rather than using an off-the-shelf solution. Later, the team learns about existing solutions, but the hand-rolled solution is now baked into the core of your application.
3. Process-Induced Debt
The process-induced variant of development debt is not strategic, resulting instead from a culture that doesn’t enable your team to deliver quality code. Author and engineer Robert ‘Uncle Bob’ Martin goes so far as to define this separately, saying “a mess is not a technical debt.” While strategic tech debt decisions “are made based on real project constraints”–meaning “they are risky, but can be beneficial”–unreasoned tech debt is not based on project constraints and is solely based on what your culture allows (or most importantly doesn’t allow) your team to accomplish.
Say your team is working nights and weekends to hit a deadline, and you skimp on testing because “we have to hit this date” and “our scope can’t change.” Unrealistic timelines without the option to vary scope will create this most insidious form of technical debt.
Where It All Leads
If you don’t keep track of how much technical debt you’re accruing, it will impact your business because you won’t know how bad things are until you’re overwhelmed with disappointed customers and non-scalable solutions. There are plenty of cases where once-dominant organizations in this situation, including the Unites States Postal Service, have had to watch competitors charge past them. According to an Accenture study, 80 percent of federal IT managers said technical debt was limiting their ability to improve legacy systems and/or move to the cloud. For the USPS, it has all resulted in FedEx, UPS, and most recently Amazon driving innovation and winning customers in the space.
If your team continues to acquire technical debt without having a clear strategy, at a certain point your velocity will just be spent paying interest on your debt. You’ll no longer have extra funds to give to delivering new features or innovative solutions. In my next post, we’ll dig even deeper into why technical debt is so bad for your company. In the meantime, use this as a primer on what technical debt really is, and reach out if you could use some help evolving your approach to paying it down.
