Prioritizing and Planning a Way Out of Technical Debt

Part one of this series covered defining, measuring, and identifying technical debt. This post covers the next step after technical debt is identified: forming a plan to reduce it.

Making a plan to reduce technical debt

Technical debt needs to be considered as a part of the product backlog. This helps to offset the cost of technical debt mitigation in the future, by addressing it as part of the current implementation plan. Allocate capacity within sprints specifically for technical debt and plan for managing technical debt in all phases of development:

Discover → Analyze → Design → Build → Validate → Deploy

Let’s take a closer look at each of these development phases as they relate to a plan to address technical debt.

1. Discover

Get stakeholder buy-in to address the problem of technical debt. To do this, you need to understand the present impact versus the future cost on the implementation.

Following the financial debt analogy made by Ward Cunningham, you can quantify technical debt using the simple interest formula:

Amount = Principal + Interest

In terms of technical debt, this looks like:

Aggregate Technical Debt = Pilot Technical Debt + Technical Debt Rate * (Unit of Time)

• Aggregate Technical Debt: Total technical debt of an implementation at a certain point in time.
• Pilot Technical Debt: Technical debt realized after the first implementation.
• Technical Debt Rate: Average technical debt accrued over a period of time.

Consider the following example. After the first implementation (release 1), the product manager finds 100 components that are flagged as technical debt. At that point in time Aggregate Technical Debt is 100 and Pilot Technical Debt is also 100.

The product owner decides to have three more releases spaced out equally during the fiscal year, that is, on every four months.

In the second release, the product manager finds 10 components as technical debt, so the Technical Debt Rate is 10 per 4 months and the Aggregate Technical Debt is now 110.

For release 3, there are 15 more items added as technical debt, making the Technical Debt Rate 12.5 per 4 months (10 and 15 averaged over 2 time periods) and the Aggregate Technical Debt is 125.

Let’s assume the project ultimately has 20 releases and use a randomizer (based on the Technical Debt Rate) to assign technical debt items to each release. You can clearly see the accumulation of technical debt increasing over time, if it is not addressed.

Depending on the trend of Aggregate Technical Debt versus Technical Debt Rate, you can define the risk level as Extreme, Severe, High, Moderate, and Acceptable.

Once a risk level is identified, the strategy to deal with the technical debt can be defined.

Strategy to Resolve: Ways to remediate existing technical debt, either by resolving it within the implementation cycle or to have a separate hardening sprint to address the problem.

Strategy to Contain: Long-term strategy to counter a high technical debt rate. For example — activities such as peer reviews etc.

2. Analyze

Follow the Crawl, Walk, Fall, Run strategy to decide on which technical debt to address first.

• Crawl — Technical debt with high to extreme risk levels (must-have).
• Walk — Technical debt with moderate risk (nice-to-have).
• Fall — Technical debt from issues that arise from addressing technical debt.
• Run — Technical debt with acceptable risk.

3. Design

In the design phase, decide on the best approach to resolve your technical debt. Approaches include:

Delete or deactivate:

• Delete (and stop using) unwanted fields or objects.
• Delete inactive Process Builder processes, flows, workflows, and automation.
• Delete any packages (managed or unmanaged) that are not being used.

Merge:

• Aggregate similar actions together under one node by adding the right conditions to the entry criteria.
• Perform a similar activity on triggers to ensure every object has only one trigger.
• Reduce the number of processes, flows, and workflow rules you have by combining the business logic into one.
• Remove any reports or dashboards that are not being used.

Optimize:

• Use a scheduled action when the user does not expect an immediate result.
• Optimize Apex code and LWC, use enterprise architecture patterns, and ensure that best practices are followed.
• From a security perspective, optimize user permissions to ensure the principle of least privilege is followed.

4. Build

Based on the design decisions and considerations, build out the resolution for each technical debt item while taking care not to accrue additional debt as you do.

5. Validate

Be sure to perform system integration testing, user acceptance testing, regression testing, and a complete end-to-end test after technical debt resolution. This will help identify any defects that may be introduced during the implementation of changes to existing components.

6. Deploy

Once all testing is signed off, deploy the updated package to production and conduct business acceptance tests as needed.

Conclusion

Refactoring and removing code is not as sexy as deploying new features. However, highlighting the negative impacts of technical debt will help stakeholders understand the importance of the mundane activities needed for technical debt reduction. By following the Discover→ Analyze → Design → Build → Validate → Deploy framework, developers can ensure that architects, business stakeholders, and other team members are aligned with respect to priorities and that key requirements and risks are addressed.

About the authors

Ankit Garg is a Technical Architect at Salesforce and has 13 Salesforce certifications. He has more than 10 years of experience in designing and building enterprise applications on the Salesforce platform. He is passionate about solving business problems by creating technological strategies, and effectively communicating the architectural vision for a successful and sustainable product implementation.

Badri Narayan is a Technical Architect with a strong technology consulting background. He has successfully designed, developed, and led deliveries of complex Salesforce solutions for multiple clients across different regions (EMEA, North America, LATAM, and APAC). He is passionate about bridging the gap between business and technology using Salesforce.

Shannon Tran is a 13x certified Technical Architect Director, Technical Consulting at Salesforce and current RAD Apex Coach. Prior to joining Salesforce, Shannon participated in the community as an author of Salesforce Finessed, a Dreamforce presenter, and through various podcasts and at Trailblazer Community led events. She has been working with enterprise IT systems for over 10 years.