Why Technical Debt is Important & How to Tackle it?
Address & tackle technical debt strategically
In this article, I will talk about the following:
- Introduction
- What is Technical Debt?
- Why is it Important?
- Causes of Technical Debt
- How to Address & Tackle Technical Debt?
Introduction
The world is moving fast, maintaining competition is becoming more challenging, companies have to adapt to that fact. They should grow rapidly and respond to change to stay alive in the market, so most of the tech companies worldwide follow the Agile methodology to achieve that.
As we all know, any technical product needs time to be designed and developed especially if we want to follow the best practices and solve many problems in an optimal way to make it well-designed, performant, efficient, maintainable, and scalable.
Business people want to adapt to change really quickly and this is expected otherwise they will be dropped out from the market. On the other hand, technical people want to develop products in an optimal way following best practices and this costs time. Business people don’t prefer to waste too much time in developing products, they want to see results as soon as possible, and if you think about it for a while you will find that it makes sense. If there is a fast way to reach the expected result (product, feature, etc.) why not go with it, right?
If you developed your product in the fastest way possible regardless of best practices and software engineering principles you will reach your results quickly and launch your product or feature to your audience and everything will be as expected! BUT eventually, you will end up struggling with the development in later phases. It’s like a bank credit card, you can use the money now to make purchases but you should pay it back later with some interest. The earlier you pay back, the lower interest you pay.
What is Technical Debt?
Technical debt is the result of prioritizing speed software delivery over perfect code. It’s the result of writing a piece of software functionality by the development team that later needs to be refactored.
Let’s walk through the following simple scenario:
Business requirement: We have to develop a feature to allow users to chat with each other and we want this to be done in 1 month.
Development team: This feature needs around 3 months of development using approach A — which follows best practices — but we can deliver it in 1 month using approach B — which is another faster approach — and we can go back and refactor it later.
In the above scenario, approach A is the optimal approach that should be followed to make sure the code stays readable, maintainable, and scalable but it costs 3 months, thus it costs more money. Approach B is the fast one that will make sure to be delivered quickly in 1 month.
Let’s say that two software engineers will work on this feature, and they take 2000 USD per month.
Cost of approach A: 3 months * (2 engineers * 2000 USD) = 12000 USD
Cost of approach B: 1 month * (2 engineers * 2000 USD) = 4000 USD
It seems that approach B is the winner BUT let’s go forward in time, imagine that this chatting feature has been developed and launched, and now after some while, we want to add more functionalities to it like sending photos and videos in the chat conversation between two users. The code is messy and the development team cannot add any additional functionality before refactoring the old code of that feature and tackle the technical debt. You will reach a point where you have to take the decision to refactor the code then add the additional functionality.
Let’s say refactoring the current code takes 4 months from 2 engineers and adding the newly required functionality takes 1 month from 2 engineers.
Cost of refactoring the current code: 4 months * (2 engineers * 2000 USD) = 16000 USD
Cost of adding the new required functionality: 1 month * (2 engineers * 2000 USD) = 4000 USD
The total cost is: 16000 (refactoring) + 4000 (new functionality) = 20000 USD
Finally, the company ended up paying 24000 USD while they could have just paid 16000 USD (12000 + 4000), which is the cost of approach A (the optimal approach) plus the cost of adding the newly required functionality. Sometimes, you need to deliver fast but be aware of how much technical debt this introduces to the product. Be smart about it!
Technical debt (also known as design debt or code debt) is a concept in software development that reflects the implied cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer.
— Wikipedia
Why is it Important?
It’s bad for software developers
Code that is difficult to work with generally hampers the productivity of developers and results in less stable code.
- Adding new features and functionalities will become more difficult
- Fixing problems will be challenging
- Developers lose motivation
- More stress
It’s bad for the development team
It also affects the development team. The cost of losing a developer is really high, not to mention the knowledge loss that occurs when a team member leaves a company.
- Higher turnover
- Reduced team agility and velocity
- Bad time estimations
It’s bad for the organization
In the modern age, technical debt can be a daunting obstacle to maintaining competition. Everyone knows that agility and resilience are strategic imperatives for companies with a product built optimally from the ground up.
- Greater friction between teams
- Slower growth in the business
- Reduced value of software artifacts
The higher the technical debt, the more complicated it is to add features. Companies usually start to recognize the importance of high technical debt at a later time.
Causes of Technical Debt
There are many causes for technical debt but the following are the main ones:
- Lack of knowledge about technical debt
If you don’t know your problem, you can’t solve it, you have to admit it first. Technical debt occurs when the development team and even business leaders lack knowledge about it because if you don’t know what does technical debt mean then you don’t know what’s your problem. W. Edwards Deming once said “Lack of knowledge — that is the problem”.
- Lack of clear requirements
It’s important to make your business and technical requirements clear to everyone because vague requirements lead to technical debt.
- Lack of standards across teams and individuals
If you didn’t set rules and standards on how teams work across the company you will end up with high technical debt. Especially in software development teams — which are the individuals that produce your software — you should set how they must design and write code.
- Lack of code testing
Code without tests cannot survive for years. Tests make your software more reliable and high quality so it will force you to reduce technical debt along the way.
- Poor technical leadership
Good technical leadership is a very important factor in reducing technical debt, they should fight against any sort of technical debt, and they should argue more with non-technical leaders who seem to be OK with incurring more technical debt. Therefore, they should develop a healthy attitude towards incurring technical debt.
- Strict deadlines and pressure that prioritize speedy delivery over perfect code
Sometimes, decisions are done by the product owner or the business leadership only. In general, the product owner or the business leadership is responsible for maximizing the value of delivery, while the engineering team owns the software and is responsible for its quality.
Therefore, decisions should be taken by collaboration between the two roles and trade-offs should be made on both sides.
How to Address & Tackle Technical Debt?
- Define technical debt
Admitting you have a problem is the first step in fixing the problem.
- Track technical debt
You can track it by documenting technical debt issues. Such documentation is helpful to bring visibility into technical debt across the teams and you can go back and fix them later in a managed way.
Project Management tools (like Jira, Trello, etc) can also be used to track technical debt, you can add issues to the backlog and solve them gradually in each sprint. Be careful not to prioritize these issues, you will end up with a lot of technical debt issues in the backlog.
Use linter tools to give you a report of all errors, bugs, stylistic errors, and suspicious constructs.
- Set standards, especially coding standards
You can also use linter tools to help you enforce some coding standards across the team.
- Give high priority for code reviews
Code reviews are the line of defense for your software, reviewers must make sure that the introduced code doesn’t increase technical debt, especially the code of junior engineers.
Technical debt might increase when any engineer in the team does the code review, the reviewer must be an experienced software engineer and he/she should be familiar with the module that he/she is reviewing. A well-experienced engineer will make sure your software stays robust.
- Write tests
Write tests for your code, especially the newly introduced code to make sure you have handled all the edge cases, and always try to cover more than 70% to maintain high test coverage.
- Refactor code frequently
Having a technical debt in your software is normal. However, not solving them frequently is a big problem.
Make it a habit to solve a couple of technical debt issues in each sprint. If you used a project management tool to track issues, you can take issues from the backlog and move them to your sprints, you can tackle them one by one based on priority.
Conclusion
All tech products have technical debt, it’s a matter of how much technical debt you have and how frequently you tackle that debt.
In my opinion, technical debt is not always bad. For example, in startups, you don’t need to develop the product in the best approach, you just want to launch your business and see if it’s going to succeed or not, it will be a waste of time to go with the costly approach because you are not sure about anything yet, all you have is assumptions.
On the other hand, when your product reaches a point where it’s so much big and complicated you should pay attention to how much technical debt you are going to leave in your code while you are developing your product.
I would like to thank you for going through this article, If you liked it please don’t forget to give it some claps!
