As per Wikipedia,
In software development, technical debt (also known as design debt[1] or code debt) is the implied cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer.
As per my opinion and / or experience, there are two kinds of technical debt - intentional and unintentional ones.
The unintentional ones stem from technical decisions that may not take the big picture in mind, where the engineer is unaware of the debt they are creating for the future. These can happen due to lack of context, lack of experience, or lack of proper impact analysis, or you know just plain human error (we are all human). Processes like pair programming, diligent PR reviews, or allocating more time on task design may be a way to mitigate these kind of issues.
The intentional ones are from deliberate engineering decisions. A team or someone decided to implement something they knew they would need to fix or refactor in the future, but decided to go ahead with it anyway due to time / deadline / business constraints. Meaning, if there is a debt, it's there for a reason, and has been put on the back-burner along with the others.
No system is perfect, and in any growing product / software, especially startups, the latter tends to happen for shorter time-to-market. "For now we will do X to solve the problem, but in the future we should do it Y to make it more generic and scalable".
Now, how to manage this debt? Like any other debt, tech debt can and should be paid in instalments. It's important for tech leads and engineering managers to be aware of tech debt, have a prioritized backlog of the same, and try to incrementally get rid of the debt over time by introducing reworks / refactors / implementations within the Sprint or regular development process as a part of normal tasks. The prioritization would happen based on a combination of business need vs which is more likely to degrade system health in the near future.
It is also the responsibility of technical leadership to collaborate with and persuade product managers / business teams on considering the additional time towards tech debt before delivering a requested feature.
For example, let's say there are some new requirements regarding SMS notifications, and the current notification system needs an overhaul. A plea to product managers would be "I know we are trying to achieve ABC with this feature to facilitate growth, however we need some time to refactor our notification system. This will allow us to implement any new notification requirements easily, plus make the notification system more scalable. If we don't do this now, with the growing number of notifications, it will degrade our performance by X hence affecting growth."
At the end of the day, both tech and business parties should work together, and be aware of the importance of technical debt, how it can affect the current system, and hence the current business. The idea is we are all working together towards a common goal.
Top comments (0)