Stripe established that developers spend a whopping 33 percent of their time dealing with technical debt. Yet so many CIOs lack a clear framework for managing technical debt. I spoke to more than 300 engineering leaders from fast-growing companies like Airbnb, Expedia and SAP to find a technical debt process that actually works.
First, let me clarify what I mean by technical debt.
Ward Cunningham, the developer of the first wiki and co-author of the Agile Manifesto, first used the technical debt metaphor as an illustration. Cunningham has since elaborated on the concept, in 2009, he drew a parallel between technical debt and personal finance:
“With borrowed money, you can do something sooner than you might otherwise… I thought borrowing money was a good idea, I also thought that rushing software out the door to get some experience with it was a good idea, but of course, as you learned things about that software, you would eventually go back and repay that loan by refactoring the program to reflect the experience you acquired.”
Rushed development means that your codebase will have deficiencies that a developer will have to rework or clean up later. These deficiencies, also called “cruft”, affect the overall code quality, and although the software can still function, it cannot reach its full potential until someone fixes the deficiencies. Fixing the cruft is like paying interest on a financial loan: it’s the price you pay for expediting the process and neglecting it can have really negative effects.
This provides us with a simpler definition of technical debt: ‘Technical debt is any code you’ve decided is a liability’.
So why is it a problem for CIOs specifically?
One of the biggest challenges for CIOs is adopting a micro view of technical debt.
CIOs and architects are used to thinking about solutions at the macro level, for example, a macro solution could be creating a one-off technical debt project where the aim is to discover all the debt in your codebase and fix it. This could be a recipe for disaster for larger enterprises as you’re dealing with millions of lines of code, it would require immense resources, time and you might end up breaking something important!
Some companies are starting to think about technical debt from a micro perspective. It’s easy to forget that technical debt is experienced by developers on a daily basis, and it all happens in the codebase. If ignored at this level, CIOs won’t even get the opportunity to understand the debt, let alone fix it. Paying down technical debt is a process, not a project.
So, what is the process that has worked for others?
The most successful companies I spoke to opted for an ongoing technical debt process that begins at the developer level, ensuring that they know exactly what to do when they encounter debt in the codebase, empowering them to take action and report it.
I heard a few different ways of doing this and merged these into a T-Shirt sizing framework, which could be used as a basic technical debt guide for software development teams:
- Small: This is technical debt that can be addressed as soon as an engineer spots it in the codebase. It might be something as simple as refactoring a function or renaming a variable. It doesn’t need to be reported or tracked anywhere, instead, try to follow Robert C. Martin’s boy scout rule: Always leave the code better than you found it.
- Medium: This debt cannot be addressed immediately, but it could be fixed within one sprint. It must be reported and tracked in order to go through the same sprint planning process as any feature work would.
- Large: This is technical debt that cannot be addressed immediately or even in one sprint. It’s crucial that this debt is reported and tracked. The best companies I interviewed have quarterly technical planning sessions in which all engineering and product leaders participate. Engineering managers are tasked with highlighting these large pieces of debt reported to them and make a business case for fixing it to senior stakeholders.
This is where the reported data becomes extremely important, the more data your engineers have reported on the issue, the easier it is to gain buy-in for fixing these larger issues.
All of these solutions start with an engineer reporting technical debt and its impact on the business as and when they encounter it in the codebase, therefore it’s crucial to give them a simple framework so they’re not wasting time thinking about what to do.
Once this reporting process gains momentum, you’ll gain visibility on your top issues that can provide the biggest productivity gains for your development team, address these and you’ll be well on your way to reaping the productivity rewards for dealing with technical debt.
Alex Omeyer is the CEO of Stepsize.
