Also known as “technical debt,” this concept in software development is about the hidden cost of solutions that are designed just for the moment—created to meet current needs instead of using a better-quality approach. Why does this happen? It’s usually about speeding up the launch of a software product.
Even though it started in the tech world, the term “technical debt” was inspired by the financial market. That’s because its effects are similar to having credit card debt: if you don’t pay it off, you’ll rack up heavy interest over time, making it harder and harder to settle. In terms of software, this debt makes code maintenance a nightmare, leading to even more delays and changes in the final product.
In this post, we’ll guide you through understanding technical debts and share a few general tips. Let’s get into it!
How to eliminate it completely?
You can’t. You heard that right. Believing that the solution to all your problems is to completely wipe out technical debt from your project is kind of naive. Technical debt is unavoidable and will always be around. All we can really do is control it as much as possible.
A simple example is code aging over time—yep, that’s a form of technical debt. So if you or your team are struggling to have zero technical debt, know that this is actually a bad sign. There’s even a name for it: Gold Plating.
Gold Plating
In project management, gold plating is when you deliver more than what the client asked for. It’s pretty common, but many don’t realize just how harmful it can be.
When you give the client more than they asked for, you might think you’re boosting their satisfaction. But it can actually do the opposite, offering solutions they don’t need or want, causing dissatisfaction that could’ve been avoided.
The attempt to eliminate all technical debt in a project is one of the main reasons why gold plating is so common in the tech world. This can bring a bunch of consequences—from driving up costs and creating false expectations for clients to increasing risks for both the project and the team.
Why does technical debt happen?
Technical debt can pop up for all sorts of reasons, from the passage of time (as mentioned) to more delicate situations.
Rushing against the clock and working with super tight deadlines leads the team to focus only on speed, not quality. That’s why setting unrealistic delivery times is one of the biggest causes of technical debt.
But there are other reasons too. They include:
- Lack of technical know-how
- Choosing the wrong technology
- The passage of time
- Lack of an iterative development process (no client feedback or testing)
Types of technical debt
Besides the different causes, there are 4 main types of technical debt. We can classify them according to Martin Fowler’s “Technical Debt Quadrant”:
- Reckless and deliberate: “We know the problem but we won’t fix it!”
- Reckless and inadvertent: “We’re working with a new programming language we don’t fully understand.”
- Prudent and deliberate: “We have a tight deadline, so we’ll deliver with these problems now and fix them later.”
- Prudent and inadvertent: “Now that we delivered the project, we know how we should’ve done it.”
How to measure and handle technical debt
Even though the idea of debt is subjective, there are several ways to measure it, such as:
- Code duplication
- Test coverage
- Fragile builds
- Commented-out code lines
- Cyclomatic complexity
- Code cohesion
Each company deals with technical debt in its own way, usually based on the methodologies they use day to day. To give you a better idea, here’s how we handle it in our ecosystem.
If you’re working with SCRUM, you can leave some buffer points so that at the end of the SPRINT, the team can tackle a few technical debt items.
Worst case, you can create a whole SPRINT or Release just for fixing technical debt. We personally don’t like doing that because it doesn’t create any real value for the end user. That’s why, most of the time, it’s better to mix and match different techniques.
Technical debt vs. Startups
When we talk about startups, we’re always talking about moving fast to test ideas. Because of that, many companies end up accepting technical debt—sometimes way too much—to get their product to market as quickly as possible.
This is a tricky topic, and to dig deeper, we need to split startups into two phases:
Before product-market fit
At this stage, the startup’s main goal is to validate its business model. Yes, it’s super important to launch the MVP as soon as possible here. A bit of technical debt is worth it, as long as it falls into the “Prudent and deliberate” quadrant.
This makes sense because it’s crucial to pick what you’ll set aside now so it can be fixed later without too many headaches. At this moment, experts and developers can really make a difference.
Scaling
At this point, it’s important to avoid technical debt as much as you can and even take care of some debts from the earlier phase. Now you’ll start to see issues with performance, usability, and architecture that came from past debts.
Here, you need to be extra careful! As mentioned before, the more technical debt you accumulate, the tougher it gets to maintain the project. From here on out, you have to be pickier about code quality: set standards, run more tests, and invest in whatever you need to ensure a high-quality result.
