Technical Debt - The good, bad, and the ugly.

Let me start with some scenarios to illustrate the concept of technical debt before providing a formal definition and discussing how to eliminate it.

Scenario #1

You are part of a startup trying to ship the latest updates to the customers and your product owner is concerned if you take two days extra to document the code and add more test cases, the initial traction you have built with the customers will die down. You are accumulating technical debt. If a new teammate joins, this person will not have any references to learn from. He might modify code and may reintroduce bugs that were fixed before.

Scenario #2

You are part of a highly unstructured software team. The development team is involved in customer interaction and bug fixes, the team lead juggles multiple roles in the team - as the software architect, scrum master, and technical team lead. Again by not creating sustainable processes and by investing too much into one resource, you are creating a dependency. If this person leaves, or changes team, the whole knowledge is lost.

Scenario #3

If you have been part of the organization for too long and sometime in the past you and your team worked on the tool. But eventually, you have moved on and the tool is not actively maintained, and then after a year, the customer wants to add features to it. You are the only one around, but you also do not remember the requirements at that time. Also, since the tool is not maintained for a year now, the libraries are all stale. It will take as much time for you as it would take a new person to add a feature to this tool.

Technical Debt - Definition

From all the examples above, you might have gotten a fair understanding of the word "technical debt"(also known as design debt or code debt. Technical debt is the result of the software development team expediting the delivery of a certain feature or a project without proper documentation, software architecture practices, or employing resources to develop automation testing.

Is technical debt bad?

Technical debt is like monetary debt. It can be good or bad, depending on how it is used. If you use technical debt to create a quick and dirty proof of concept, it can be a valuable tool. However, if you use technical debt to create a system that is not scalable or maintainable, it can be a serious problem. Sooner or later, you will have to rewrite the entire system because it is not scalable, or, did not discuss the requirements properly.

Like borrowed money, if you do not pay it back, it accumulates interest. Similarly, if you remember to maintain the code, refactor it when necessary, and document and write test cases, then you are keeping the yin and the yang together.

How can you eliminate technical debt?

You may not be able to completely get rid of technical debt, but you and your team can reduce the ramifications of it by:

1. Allocating resources and prioritizing code documentation,
2. Paying attention to testing and test case development,
3. Refactoring the code when necessary, and,
4. Updating libraries

I would love to hear how your team is tackling technical debt (design debt or code debt). Do let me know in the comments!