Understanding tech debt
What is technical debt ?
You’ve probably heard of the term ‘technical debt’. But what is it exactly? If you work in a product engineering team, you need to understand it.
3 min read
It’s impossible to work in software without hearing about ‘technical debt’.
While we use the term often, it isn’t well understood. You’d probably define it differently than your colleagues.
That’s because technical debt was coined in 1992; software development was in its infancy back then. Agile was popularised 9 years later, and it would be another 4 years before Git was created!
30 years later, the industry has grown up. But how we think about tech debt lags behind.
At Stepsize, we spoke to hundreds of software professionals about tech debt. It quickly became clear that the industry needed new mental models.
The origins of the term ‘technical debt’
Back in the ‘80s and ‘90s, engineers and business folks spoke different languages.
Waterfall development was the standard. Requirements were lobbed over the wall to development teams along with simple instructions: get it done before the deadline!
Ward Cunningham needed a way for higher ups to understand the importance of refactoring existing code that was no longer fit for purpose:
"Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with refactoring... 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."
In other words: it’s ok to take shortcuts when building software, but at some point you need to go back and do things properly.
30 years later, the tension between business and technical requirements is stronger than ever.
Why spend time refactoring code when we can spend our time shipping features ?
The ‘features vs refactoring’ fallacy
Shipping a feature is like remodelling your kitchen.
You don't start from a blank slate. You have to delete some pieces of code, replace others, and write new ones to create a cohesive whole.
So the right question to ask is not "should we refactor this code or should we ship this feature ?"
It's "which code should we refactor to ship this feature ?"
Refactoring is an integral part of software development. You don't get to choose between features and refactoring.
A broader definition of ‘technical debt’
Technical debt is code that makes it harder for companies to achieve their goals. It's code that has become a liability.
Whether that’s shipping a new feature, beating competitors to market, or building a happy and high-performing engineering team. Some existing code always stands in the way.
Sometimes it's easier to work around tech debt than to fix it. Often it's not.
Regardless, teams need to make conscious decisions about technical debt to perform well. Ignore it at your peril.
Where technical debt comes from
In the next chapter, we’ll explore where technical debt comes from.
Ward Cunningham’s metaphor suggests that it’s the result of taking shortcuts during development.
This is often the case, but tech debt can have many different origins.
