Tech Debt aka technical debt is part of the software engineering development process. This is also known as Code debt sometimes. The immediate question that pops up is all tech debt bad?
The simple answer to that question is – It depends.
Some tech debt is intentional and some is unintentional. As we explore this topic as part of the software engineering development process, it is necessary to understand every developer has to pay back the debt at some point in time.
What is Tech Debt?
Technical debt is a quick and dirty solution to a software problem. In many cases, to launch an MVP (minimum viable product), engineers come up with a quick solution. It’s not necessarily that a quick solution is bad. But if it is not thoroughly tested in real-world scenarios, it can cause some downstream effects. Is all technical debt bad? Technical debt gives a sense that it is bad. But it all depends on the scenario you are working on.
If you are implementing a solution quickly, it might align temporarily with the expectation, but might not always be right. This is where technical debt comes into the picture. Recognizing technical debt is necessary. Addressing the debt depends on the situation.
You can not prevent technical debt. In many cases, you do not have all the information when you are building a solution and you have to make assumptions.
Bad code is not necessarily a tech debt. But it can incur a cost in long term and that would end up being a tech debt.
Types of Tech Debt
Let’s look at different types of tech debts.
Intentional Tech Debt
To release a product to market early, many times engineers and stakeholders reduce the scope of the requirements. In many cases, everyone involved had to make choices, and that ends up causing an intentional tech debt. To get user feedback quickly, the product makes such a choice and accepts the fact the performance can be poor, the product can be unstable. There is an inherent risk involved with intentional tech debt.
Unintentional Tech Debt
On the other spectrum is unintentional tech debt. Most of this tech debt arises from the complexity of requirements and products. Product managers, domain experts, and engineers make assumptions in case of complexity. With unknowns involved, it becomes really hard to predict what can cause issues with the product. In such cases, engineering teams cut corners, and test the product insufficiently. If teams can recognize this debt, they can address it. Engineering teams have to adjust their development process to address this debt.
Environment Tech Debt
When engineers build a software product, it involves multiple third parties like libraries, other vendor products, or software. As time progresses, if engineers don’t keep the product up-to-date with various components, the product can start accruing an environmental tech debt. The most serious of tech debt in such cases can be a security threat. If engineers don’t patch libraries on time, security vulnerabilities can expose the product to risk. This kind of debt is recognizable over time and the teams involved need to remain on top.
The Effects of Tech Debt
There can be effects of tech debt both business-wise or financially.
- Poor user experience
- Security concerns and issues
- Reduced time for feature development
- Possible loss of customers
- Lower productivity
Managing Tech Debt
As previously stated, engineers need to address tech debt at some point in time. How do you manage tech debt then?
- Make time to address tech debt. Once tech debt is identified, engineering teams should make time to address tech debt to avoid the long-term effect.
- Separate good debt and bad debt. Address bad debt sooner. Evaluate if good debt is to be kept in the system for a long.
- Measure the impact of tech debt. If you can create performance metrics around tech debt, measure the performance. This gives clarity on how the debt is affecting and why it needs to be addressed.
- Adopt the new processes and quality reviews to avoid future tech debt.
Conclusion
In this post, we talked about technical debt and the kind of impact it can create on user experience and business. As an engineer, it can take the experience to identify this debt. But always make sure to make time to address the tech debt.
If you want to learn more about how to implement two-factor authentication with spring security, here are my previous two posts