Reduce Technical Debts

In this article, I will discuss how to Reduce Technical debts Definition of done is the quality checklist for Increment. However, even when you have a checklist, sometimes people take shortcuts. These shortcuts create “technical debt.” The term technical debt was coined by Ward Cunningham. Financial debt is owing money or a loan. When you take on a debt or a loan you get early to access to money which you have not earned. So, it is short cut to money. These loans can be taken out for various reasons. To invest and increase the money (a good reason), medical emergency (unavoidable reason), party in Vegas (frivolous reason). But every time we take out a loan, we need to pay interest on money owed. Similarly, technical debt is a shortcut we take to reach to goal quicker. We end up taking these shortcuts for many reasons. Below in this article, I will get in details about reasons why we may incur the technical debt. But we pay for these shortcuts later. It takes more time to fix or change. For example, sometimes we may write code fast without any code review or unit testing. This code might not be the best. Later, we have to spend time fixing it. This extra time is like the “interest” on the debt

Few Reasons behind technical debt

Pressure for Rapid Delivery: Intense focus on meeting tight deadlines or achieving quick market entry often leads teams to take shortcuts, postponing best practices like thorough testing, refactoring, or optimal design.
Business Decisions & Prioritization: Sometimes technical debt is incurred deliberately as a strategic choice, with the (sometimes unfulfilled) intention of addressing it later. Sometimes this may be due to a conscious call of delaying some activity in order to ensure early delivery. Sometimes we make a conscious choice to delay certain work due to budget constraints (licenses or infrastructure)
Evolving Requirements: When product scope or user needs change significantly after initial development, adapting the existing codebase without proper redesign or refactoring can introduce complexities and quick fixes that constitute debt. An example can be, we build a ecommerce product for niche audience, but after the launch the product is super-duper successful, and we decide to launch globally. This is indeed a good thing. But it does create a problem, where now we need to do performance testing even for the code which is in production. We have incurred a technical debt!
Lack of Awareness or Understanding: Teams might not fully grasp the long-term consequences of certain design choices or coding practices, inadvertently introducing debt due to insufficient experience or knowledge.
Insufficient Skills or Training: The development team may lack the necessary expertise in specific technologies, design patterns, or best practices, leading to suboptimal implementations.
Inadequate Design and Architecture: Rushing the initial design phase or failing to establish a robust, scalable architecture can make future modifications difficult and prone to workarounds.
Neglecting Refactoring and Maintenance: Failure to allocate regular time for cleaning up code, improving its structure, and removing redundancies allows complexity and inefficiencies (debt) to grow over time.
Poor Testing Practices: Insufficient automated or manual testing can allow bugs and design flaws to persist, often leading to quick, localized fixes later that don’t address underlying issues and contribute to debt.

Types of Technical Debt

Technical debt comes in many forms. Each form causes different problems.

Code Debt: This is common. It happens when code is messy. For example, you copy and paste code. You do not write tests. This makes code hard to change.
Architecture Debt: This is about the system’s design. If the design is bad, the system is hard to grow. For example, you do not plan for future needs.
Testing Debt: This happens when you do not test enough. Without tests, you miss bugs. Bugs make the software unstable.
Infrastructure Debt: This is about the tools you use. For example, old servers or bad setups. This slows down the system.
Documentation Debt: This happens when you do not write good instructions. People do not understand the code. This slows down new team members.
Process Debt: This happens when agile rules are ignored. For example, skipping code reviews, or not refining the backlog.
Design Debt: This is about the user interface. Bad design makes the software hard to use.

Some strategies to reduce technical debt

Find and Track the Debt: First, you need to know where the technical debt exists. Teams should actively look for problem areas in the code. Then, they should list these issues and keep track of them.
Represent Technical Debt in Product Backlog – Reducing technical debt means the Scrum Team has to do some work. In Scrum, we add all work to product backlog. That helps us to have transparency about ALL work needed for our product. Adding technical debt to Product backlog helps to keep the technical debt visible. It will also spark discussions about why reducing the technical debt is important.
Use Capacity Allocation: It helps if we can dedicate specific time or a % of bandwidth just for fixing technical debt. Assuming you will find time later to fix can be risky and lead to unpleasant surprises later on. An example of this strategy can be to decide that 15% of every work week goes towards cleanup tasks.
Leverage Definition of done well – Make sure that the definition of done includes all the quality work needed. This will mean we will consider this effort in Sprint Planning and avoid delays or shortcuts later. Team may also consider multi level definition of done to track quality practices that can not be followed every sprint.
Focus on High-Impact Debt: You probably can’t fix all debt immediately. So, figure out which debt causes the most trouble. Prioritize fixing the issues that significantly slow down development or lead to the most bugs.
Clean Up Code Regularly (Refactor): Make it a habit to improve existing code. This involves cleaning up messy parts and simplifying the structure without changing what the software actually does for the user. Regular refactoring prevents debt from piling up.
Improve Testing: Write more and better tests, especially automated ones. Good tests catch problems early. They also give you confidence that fixing debt in one area doesn’t accidentally break something else.
Use consistent Checklists: The team should agree on and follow consistent coding standards. When everyone writes code in a similar way, it’s much easier for others to read, understand, and maintain it, reducing future debt.
Peer review: Before new code gets added, have another developer look it over. Code reviews help catch mistakes, ensure standards are met, and share knowledge across the team.
Talk to Business Stakeholders: Explain technical debt clearly to managers or clients. Show them how fixing debt now helps deliver features faster and with better quality later. Getting their support is crucial for dedicating time to fix it.
Keep Tools and Libraries Updated: Regularly update the software libraries, frameworks, and tools your team uses. Working with old, unsupported technology can be risky and makes fixing other debt harder.
Fix Debt Incrementally: Avoid trying to fix all technical debt in one massive project. Instead, break it down. Tackle smaller pieces of debt regularly as part of your normal workflow. Consistent small improvements add up.

Challenges to Expect

You will face challenges when dealing with debt.

Balancing Time: It is hard to find time to fix debt. You must also build new features.
Measuring Debt: It is hard to know how much debt you have.
Resistance: Some people do not want to refactor. They think it is a waste of time.
Changing Needs: Requirements change often. This makes it hard to keep the code clean.
Old Systems: Old systems are hard to fix. They are complex.
Team Changes: When people leave, knowledge is lost.
No Support: Management might not care about debt. You must explain why it matters.
Time pressure: The need to deliver new features can make it very difficult to find time to address technical debt.

Conclusion

Technical debt sometimes becomes unavoidable but entire Scrum Team needs to work hard to keep it contained