Technical Debt: Consequences of Ignoring it
What is Technical Debt?
If you ask any product owner, scrum master or developer, they will vouch how hard it is to manage the project constraints and offer the best possible technical solution. Sometimes we have to cut some corners to meet deadlines. Technical debt is the term that refers to the cost of additional rework caused by choosing an easy solution instead of using a better approach that would take longer. It can also refer to long-term costs incurred because the software has not been designed properly from the start.
Technical debt can be seen as one type of trade-off between short-term and long-term priorities. The term was coined in 1993 by Ward Cunningham, one of the pioneers of the early days of personal computing. In this day and age, many academic papers and specialists discuss many types of technical debt, including code debt, design debt, documentation debt, and process and people debt.
How and Why Technical Debt is Created?
Most software platforms and applications have some amount of technical debt. A new project, for example, starts with the assumption that all code is fully tested, bug-free, and use-case specific. This is a blessing in disguise because it lets the software be quickly delivered to the market with minimal risk of failure. However, this approach means that the majority of the time over which development takes place is spent on developing functionality. During each sprint, some bugs will be reported, and most critical bugs are getting fixed. However, there will be some ‘minor’ bugs which will be kept unattended. When enough features are developed and bugs are fixed, the software will start moving through alpha, beta and, finally, the release. While teams are busy working on features and critical or major bugs, minor bugs may start filling up on the side. Similar to bugs, other technical debt can be created in the process either due to a rush to complete things or simply by neglecting some low-value items.
Martin Fowler, a specialist in software engineering, introduced the technical debt quadrant, which explains technical debt in the context of intention (deliberate vs inadvertent) vs choice (reckless vs prudent). The quadrant approach helps us understand that reckless technical debt should be avoided at all costs. Any technical debt created from recklessness is unlikely to be addressed during the lifecycle. However, any prudent decision taken deliberately or due to inadvertent circumstances is likely to be fixed mainly due to the awareness of the technical debt.
https://martinfowler.com/bliki/TechnicalDebtQuadrant.html
Why You Need to Fix it Now!
In today’s business landscape accumulating technical debt can become a huge issue in no time. Unlike those olden days when people were happy with basic needs, today’s customers demand new features every now and then. Once a team get into adding more and more features time, they have to fix any technical debt that might be low to none.
Technical debt is not just a problem for developers. Technical debt is a problem for the entire business. If you don’t fix it now, your company could be headed for disaster. Technical debt is a major concern for many companies today. It can be difficult to prioritize fixing technical debt in the midst of all the other things that need to get done, but it’s important to remember that if you don’t fix it now, your company could be headed for disaster. What are the consequences of not fixing your technical debt? — Slow loading times — Unstable system — Inefficient code — Security vulnerabilities — Hardware limits — Falling below industry standards.
Agile could be a way to either create a technical debt spiral or a way to minimize it. If you follow agile as a way to focus only on the delivery, it could create a technical dent which is not getting resolved. A definition of “Done” that only looks at a mediocre quality which is sufficient to get through the QA process will create layers and layers of bugs which could go out of hand in no time. However, refining the definition of done and maintaining the backlog focusing on the quality of output could positively impact the technical debt.
Another important thing to minimize technical debt is to educate the team on the cost of technical debt. If the team is aware of the consequences and costs, they will focus more on ways to minimize technical debt. Modularized architectures and automated testing could further reduce the likeliness of technical debt creeping into projects.
Conclusion
Leaving technical debt unaddressed might have severe repercussions for a product or an organization, including low team morale due to constant issues reported, slower uptake of products, customer dissatisfaction and poor security and compliance. The important thing about technical debt is that it can be managed and minimized. There are many ways to do this, but one of the most popular approaches is to use a technical debt tracker. Adopting proper agile practices could help reduce and track technical debt. Most importantly, remember technical debt is a reality for any team. The important thing is to be aware, manage it and avoid it going out of control.
