Does not matter if you’re a Node.js developer, a Python engineer, a React / Front-end wizard, a product manager or the CEO. Good chances you’ve heard of technical debt. And if you have not, or you have lack any understanding of technical debt I’ll grantee you’ve been on the receiving end of it and have not realized.
In this post I’ll try to outline and get you understanding technical debt. What is it and why it’s actually worse than debt. In our next post we’ll deal with how to manage or deal with it.
What is Technical Debt?
A quick way to understand technical debt is to look it up.
According to Wikipedia, the definition is:
a concept in software development that reflects the implied cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer.
However Technical Debt, in my view is much more broad. It’s any code that has issues such but not limited to:
- Is not easy to maintain
- Hard to read
- Has code duplications
- Lacks testing
- Not well engineered
- Has very long functions doing many different things
- Is not modular, and compartmentalized, as functional or OO
- Many others…
Types of Technical Debt
While it’s possible to categorize many types of technical debt I’d like to bucket them into two types of technical debt you most likely have in your systems today.
The Wikipedia term identified that type of debt. It’s when we logically make a decision to under engineer or hack a solution together, rather than build software that is well crafted, designed and easy to maintain.
There are many times reason to do that (i.e. experimenting with a new feature, temporary solutions, proof of concept, deadlines, and more).
Wikipedia does dive deeper, and shows a quadrant of types, which is nice, and bit more helpful. But I believe the underlining assumption that Technical Debt is a choice is flawed.
Much of Technical Debt in the best case scenario, is a result of knowing better after, as identified in the inadvertent part. As we always know better in retrospect
(i.e. we have a much better understanding of how a piece of code should be used after we have written it and sent it out to the wild, a bit like the “lead startup”)
However I think that again makes a graceful assumption. a lot of “accidental” debt is generated, by bad software developers (experienced as they might be),
by lack of good software design practices such as rushed code reviews for example, not following DRY principle, inventing rather than using existing design patterns,
junior developers writing code that “works” but never properly reviewed, multiple contractors working on the code, technical decisions made by managers that lack technical knowledge nor listen to their technical team,
and many more reasons.
Why it’s worse than debt?
Warn Cunningham coined the term Technical Debt back in 1992. The term draws similarity to financial debt.
In that regard, you’re “borrowing” time by implementing quick/bad code today, which would need to be repaid in future re-work.
While this all sounds lovely and novel, it’s fair from reality.
In fact when you have a better Understanding of technical debt you’ll realize that it’s considerably different and worse that financial debt.
Financial debt is very well defined, technical debt is not:
|Technical Debt||Financial Debt|
|How accumulated||Intentional / Accidental||Only Intentional|
|Is Avoidable||No||Yes, you can live without debt|
|Amount “Borrowed”||Not Clear||Exact, documented in contract|
|Repayment Schedule||Not clear, No defined, not easily quantifiable||Exact, documented in contract|
|Typical Interest Rates||Not defined. Can be 10x or more!||Well defined in contract, normally 5%-10%|
|Non-Payment consequences||No one knows. Can be huge / loss of business!||Well defined in contract|
This table is not complete, while it’s not hard to think of many more ways tech debt is different to financial debt. It’s not the point.
Is it avoidable?
What you have to remember, is that Technical debt is unavoidable and exists in all companies in the world! Let me repeat that once more.
You cannot avoid Technical Debt. You just can’t even if you have the best software developers in the world, just by the mere fact that you will know how to do things better, once you’ve done it.
As such accept you’ll accumulate Technical Debt, that’s money back guarantee!
eBay Case Study
Let’s look back at eBay in early 2000’s. They were world leaders, in a perfect position to be the online market to buy and sell everything online.
And today? They are still in business, and work well, but they have lost all their edge. People use Amazon a lot more, and many other website instead of them.
So what happened? Technical debt did. Their systems were complex, rigid and filled with issues.
Here an excerpt from a WSJ article:
eBay’s system, which involved 25 million lines of inflexible code, soon became a liability. The company, for example, couldn’t figure out which of its hundreds of thousands of ‘iPod’ listings were for a given model or for iPod accessories. EBay’s challenges with outdated technology are common for Web pioneers, whose systems were built with custom software that is now too old and rigid to adapt to a competitive and fast-moving market.
So in reality there system prevented them from moving quickly, by the time they had to “re-write many of their systems” ending in them losing their competative edge.
So What should I do
Most chances are your systems are in a much worse state than eBay’s. Most chances are you have lots of Technical Debt that needs to be paid.
Does it mean that all is gone, and you’re doomed? No, there are many paths forward. One this is sure you have to start thinking about technical debt and how to address it today.
I believe at this stage you have a much better understanding of technical debt, which is a great start.
In the next part, we will discuss how to tackle technical debt and how to prevent your company from hitting the same walls that eBay did.
Until next time.