In order to have a meaningful discussion, let’s first define what we mean by “technical debt.”
Similar to financial debt, it means borrowing resources from the future in favor of the now. We want to achieve something in the short term, knowing that we’ll have to pay it back later, with interest.
A classic example is implementing a feature “quick and dirty”, and only after it’s proven to be successful for our business, pay it back and make it “clean”, i.e. code that was written by someone who cares.
Is technical debt a bad thing?
The not so simple answer is “it depends”. In some cases, it can be a good thing, but if not paid back can have severe negative impacts.
How technical debt can be good
Imagine two competing companies:
Company A is building its product and keeping zero technical debt. It means that they are heavily investing on the technical side, moving “slowly but surely”.
Company B is building its product while accumulating technical debt and documenting it.
Which company will reach the market faster, learn what is required by the market, and deliver value?
Most likely it’ll be company B that is adapting to markets and requirements, shaping a valuable product. They can pay the technical debt, or a part of it, at a later point in time after they prove to bring value.
Company A might have the perfect code, but it may not bring any value, and thus, won’t be used at all.
Company B did not prematurely invest a lot on the technical side, and therefore can decide when to invest more. This type of technical debt is the result of a deliberate decision – what to focus on and what to neglect now, assuming it will be worked on it in the future.
Technical debt is very common for new companies, new products, and new features, that are defined as a proof of concept or an experiment – we’re not sure if we’d keep it around as it has a high potential of failure or being changed, so we focus on delivery and learning.
If it succeeds (and ideally the success criteria are decided beforehand), we invest in improving the neglected parts. If it fails, we remove it.
How technical debt can be devastating
On the other hand, technical debt can have terrible consequences, especially when it is the result of recklessness or lack of awareness.
“Recklessness” means that engineers know that the time is right for investing in the technical aspect, but due to time pressure, peer pressure, or laziness, choose to ignore it and deliberately make a poor choice.
“Lack of awareness” means that engineers build something in a certain way that is not ideal because they are either unaware of the implications or unaware that a better way exists.
Let’s look at a few different examples of technical debt – Actually, “Software Entropy” would be a better term, as it’s broader and contains other types of debt:
Types of Software Entropy
- Lack of tests – unit tests, component tests, contract tests, integration tests, end to end tests
- Bad design – wrong design decisions initially made (with the information at hand at that point in time).
- Lack of needed documentation – This includes documentation of the code, a setup readme, reasons for changes, the actual product, troubleshooting, and FAQs
- Nondeterministic workflows – For example, the order of events is not guaranteed and cannot be relied on
- Ignorant management – pressure for features, not allowing quality work or time
- Pending tests – tests that for various reasons are marked to be skipped
- Bad architecture – not cohesive, too many dependencies, too coupled, not secure enough, doesn’t support required scale, not easily changeable, not reversible
This list provides just a few examples of technical debt or “Software Entropy.” A more comprehensive list of examples can be found here.
Software entropy can be both good and bad
Technical debt can be a good thing when you want to implement something quickly to determine if something adds value and is worth keeping or if it doesn’t add value and should be tossed out.
However, when it isn’t paid back, the impact on your company, product, or feature can be devastating. This is where understanding the implication of technical debt, then examining how to deal with it, becomes crucial. Whether or not it is deliberate, technical debt will have some kind of impact on your organization – and it’s up to you to determine if the implications will be positive or negative.