How to Manage Technical Debt š¦
And how to prioritize it against product features and other initiatives.
Hey š this is Luca! Welcome to a āØĀ weekly edition ⨠of Refactoring.
Every week I write advice on how to build great engineering teams, backed by research, case studies, and my own experience.
If you want to receive a full article like this every week, consider joining other 16K tech leaders and subscribe to Refactoring!
The full subscription also gives you access to the private community and the curated library.
About a year ago I stumbled upon an old video by Ward Cunningham, one of the original Agile fathers, about technical debt.
There he described debt asĀ the natural result of writing code about something we don't have a proper understanding of.
If we fail to make the program aligned with what weĀ understandĀ to be the proper way toĀ think aboutĀ our [...] objects, then we are going to continuously stumble intoĀ disagreement, and that would slow us down like paying interest on a loan.
The video and the quote above inspired me to write a full article about the elusive meaning of technical debt, which as of today is still my most popular article ever, with more than 50,000 views.
The article focused on what technical debt really is and how you can prevent it in various scenarios. It did little, though, to help you address and reduce debt once itās there.
This new article is a practical, thorough guide to managing technical debt with your team, from the quarterly strategy down to the day-by-day.
It covers:
š„ The impact of technical debt on your team
š How debt changes with product maturity
šāāļø How to address it: small vs medium vs large debt
āļø How to assess technical debt
As always, the article takes from my own experience, plenty of readings, and conversations with the best engineers I know.
Most of all, it is a joint effort with folks from the Refactoring community, who have been invaluable in sharing real-world processes and examples (shout-outs inside the article). You can find here a sneak peek of the main thread.
Letās dive in š
š„Ā The impact of technical debt
We all have an intuitive understanding of how technical debt can drag down engineering teams, but how so?
I talked with Alex Omeyer, who surveyed 200+ engineers and managers around technical debt. Here are the insights that struck me the most:
58% of companies have no process for managing technical debt.
66% of engineers believe the team would ship up to 2x faster if they had a process for technical debt.
52% of engineers believe that technical debt negatively impacts their teamās morale.
Quoting Alex:
I was surprised to see such high numbers, but I can empirically validate them. Think of it this way: how many times have you estimated a feature would take the sprint, and it ended up taking two, or three? Now imagine this at the scale of an entire company and the ramifications it would have. Itās not hard to believe that companies who truly have a good handle on their technical debt ship twice as fast as those who donāt.
Technical debt mostly affects velocity and morale ā and companies that have processes to address it constantly outperform those that donāt.
Is all debt created equal, though? Does this stand for all products and companies?
šĀ Technical debt vs product maturity
When it comes to startups and fast growing products, you may hear about taking on debt intentionally, as the result of prioritizing speed and growth over engineering quality.
Regardless of whether this would make for a good strategy, debt is most often inevitable rather than intentional. Fast growth, in fact, naturally leads to technical debt, because when the product changes at a fast rate, your engineering abstractions get invalidated equally fast.
Such volatility, though, changes with the maturity of your product. For the sake of simplicity, letās consider three stages:
0 to 1 ā you start building a product from scratch, with a set of initial assumptions.
Product Market Fit ā you figure out what works, double down on it, and scrap the rest.
Scale ā you grow your business predictably and harden your tech.
The earlier you are on this scale, the more your product needs to move fast, and the more leverage you get by accruing debt.
The later you are on the scale, the more debt becomes a drag that prevents your product from growing. Your scale is such that you get the most leverage by repaying debt.
For early stage startups it might be inevitable and even healthy to accumulate debt early on. At the same time, though, you should create processes to help repay debt from the very beginning.
Letās talk of processes š