Strategies for “Managing Technical Debt”

It is virtually impossible and challenging to void technical debt in any software development project. Especially in Agile paradigm, meeting the timeline for sprint after sprint, keep adding technical debt. There are few major reasons, due to which technical debt generated each sprint / delivery cycle -

• Scarcity of enough time to deliver feature / enhancement.
• Lack of adherence to coding standards
• Lack of understanding of the acceptable quality
• Lack of regression testing
• Lack of Test Driven Design (TDD)
• Lack of Code Review / Peer Review
• Increase in defect count

All these add impediments to the high quality and streamlined delivery of code. If the technical debt is not managed regularly and diligently, it increases exponentially and reduces the velocity of team and impact the overall quality and stability of code big time.

Depending upon situation, there are different strategies we can apply to manage the technical debt. There are possibilities where, we can apply multiple strategies to manage the technical debt, e.g. one strategy to prevent Technical Debt and at the same another strategy to reduce existing technical debt.

Following are 2 strategies which we can use to manage technical debt

Strategy 1 – Defining status “Done” and Preventing Technical Debt

It is always seen there is gap between “Sprint Done” and “Production Done”. Due to this gap, code delivered by the end of sprint or delivery cycle may not be always production deploy-able code. There may be code quality issues due to ignorance of coding standard. There may be skipping OR inadequate unit test cases due to scarcity of time.

To address these issues in advance, it is very important to create a correct definition of “Done”. And making development and testing team aware of acceptable standard of quality. Status of feature cannot be marked as “Done”, until an acceptable level of quality is accomplish before committing the code. This can help to prevent the Technical Debt upfront.

·        There are different tools / IDE plugins available (findBug, SonarLint etc), which can help developers to scan their code and identify potential issues in code before commit. This is pre-commit check of code to prevent code quality issues.

·        There are also IDE plugins (Clover, Cobertura etc) available for scanning code and report the code coverage. These plugins can be used to scan the code and fix the code coverage issues and bring test coverage to acceptable level before committing the code.

If we create pre-commit check culture within development team, we can prevent technical debt up to significant extent. Preventing future technical debt is the best strategy to manage it.

Strategy 2 – Identify, Quantify and Prioritize existing Technical Debt

As we know, something we can’t measure, we can’t manage. Same is applicable to technical debt, the first step in effective management of technical debt is to “Identify and Quantify” technical debt.

Identify and Quantify Technical Debt:

There are quite a few tools / services (SaaS) available, which can scan the existing code can provide comprehensive report of Technical Debt. The reports can be in terms of violations, man-days and severity. Some of them also gives SQALE ratings of existing code. Which can help development team and product owner to understand where product stand in terms of quality and how much efforts to spend to attain acceptable quality.

Prioritizing the Technical Debt:

    In order to prioritize an identified Technical Debt items, one need to do thorough analysis of each item / category of Technical Debt. This is one of the exhaustive but most important activity in effective management of “Existing” Technical Debt. While doing this comprehensive analysis efforts, there are multiple factors need to consider to avoid spending time and efforts in fixing Technical Debt with low ROI (low business value).

    However, Technical Debt related to Security, Performance and Reliability need to be prioritize to avoid potential security breach, application performance issues and unexpected behavior of functionality.

    Coming back to other categories list like Maintainability, Re-usability, Portability, Changeability etc, it is very important to consider ROI. 

Technological Value: After analyzing and putting the figures in graphs as above, it can give clear insight of high priority items that should be targeted first. Looking at above graph, it is evident that TD1 has high ROI, if we target it first. However, we also need to consider one more factor while prioritizing the Technical debt items and that is how long we need to bear with pain related to particular Technical Debt item.

e.g. Technical Debt item is related to a functionality / application, which will be important and frequently enhanced over next 6 Months or 1 Year, and if it is not maintainable easily. Then this will add more pain every time, development team enhance this functionality / application. This is the factor need to consider while quantifying the pain related to any Technical Debt Item. This will give accurate ROI factor to help prioritize Technical debt Items.

Business Value: Above analysis is only one side of a coin and only considers IT decision making for Technical Debt. However, all the IT efforts are driven by business needs and should have significant business value to it. In order to complete the prioritization analysis for each Technical Debt item, one need to evaluate the business value for fixing that item. Some Technical Debt item may be related to application / functionality with high business value (generating more revenue / customer satisfaction) and some may have comparatively low business value. In this way we can complete the prioritization analysis based on alignment with business value.

    Strategic Value: One more factor we need to consider while prioritizing Technical debt Items is application landscape and future need of business. Not all the applications in company’s portfolio has equal business value. Some of them are has more business value and will continue to serve business critical needs in foreseeable future, while some of them may be legacy applications and may be on decommissioning road-map. Such legacy application may not have high business value. These are some of the factors need to consider while evaluating strategic value of application / functionality.  

Summary

    It is quite evident that Technical Debt is major obstacle in streamlined and continuous delivery of high quality and high value of product to the business. Based on above discussion, we can apply Strategy #1 to new development projects and Strategy #2 to new applications as well as existing applications which are running in production. As mentioned earlier there may not be single strategy best fit for any particular application, but we need to come up with strategy based on the factors discussed in above two strategies.