By: Prateek Kumar Singh Sengar, Principal Salesforce Architect, LTIMindtree

Introduction: What is technical debt?

You will learn multiple definitions of technical debt depending on whom you ask. A simple Google search will yield dozens (if not more) results with definitions of technical debt. It’s generally believed that Howard Cunningham (developer of the first wiki and co-author of the Manifesto of Agile Software Development) coined the metaphor Technical Debt and then later refined its definition as:

“Shipping first-time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite. The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.” (Source: medium)

In simple layman’s terms, technical debt can be defined as:

A consequence of software development decisions that prioritize short terms gains vs. delivering quality and efficient code.

Now that we know how to define technical debt, it’s essential to recognize that some amount of technical debt is inevitable. IT leaders and teams are always required and expected to balance business priorities, time to market, cost, and quality of the deliverables.

However, when technical debt is left unchecked or is not appropriately managed, it can quickly build up and lead to one or more of the following issues:

• Loss of productivity
• Low release velocity
• High maintenance cost
• Performance issues

Why do we need to measure technical debt?

As mentioned above, technical debt can have real consequences, leading to a loss of productivity and sometimes a loss of competitive advantage. Therefore, having technical debt management as a top priority in the organizational roadmap should be a no-brainer.

The reality is, however, a bit more complicated. Even though IT teams mostly recognize the consequence of tech debt, the business sponsors/stakeholders cannot relate to these consequences in a way they can engage.

I am not implying that business users are clueless about the consequence of technical debt. In fact, in most cases, they know there are “some” consequences of taking these shortcuts; they think the impacts are minor and can be fixed “later.”

So, does it mean that it’s the responsibility of the IT team to present the consequence of technical debt to the business users in a way they can relate to? – Absolutely, yes.

How to measure technical debt?

Let’s take a quick look at some KPIs that can be used to measure the true impact of technical debt.

• Story point inflation
  The true impact of technical debt, like financial debt, is much more than the borrowed effort you can repay later. It often has an incremental interest that accumulates with each release. Comparing the measure of current features with the past ones (for similar tasks) is a good indication of the state of your technical debt.

  If you notice a trend where similar tasks/activities are taking significantly more time than the previous release, it’s time to invest in fixing the underlying issues.

• Measure unplanned work
  Unplanned work is any task you must perform due to bugs, service interruptions, or flawed software designs. Unplanned work is problematic since it steals capacity and leads to inherently unpredictable delivery that turns an organization into a reactive rather than a proactive entity.

  Note: You cannot wholly eliminate unplanned work; a good baseline that most teams like to follow is to keep the unplanned work under 15%.

• Measure the technical debt ratio
  The technical debt ratio is the cost of fixing a software system vs. the cost of developing it.

  Technical Debt Ratio = (Remediation Cost / Development Cost) x 100%

  Higher TDR means a poor-quality state; most teams prefer to keep the TDR below 5%.

  (Source: medium)

• Code quality metrics

  Several metrics are available to quantify overall code quality and complexity; some of the most common metrics used are:

  • – Cyclomatic complexity
  • – Lines of code
  • – Code comment density
  • – Test coverage
• New bugs vs. close bugs
  Keeping track of the number of new bugs vs. the number of closed bugs can also be a good measure of technical debt. If regular enhancements or maintenance activities are causing more bugs than they are closing, it points to either poor quality or a lack of understanding within the team. Both are signs of technical debt.
• Developer happiness
  As mentioned earlier, technical debt slows or hinders the development process. Anything that creates friction between developers/engineers and their work reduces the quality of their output and their happiness.

  According to a study by Stepsize, 51% of engineers left or considered leaving their job because of technical debt. (Source: Venturebeat)

  Measuring developer happiness is, therefore, a critical but often overlooked parameter to measure the impact of technical debt.

Put an action plan to tackle technical debt

Step 1: Identify and document technical debt
One of the reasons technical debt is so hard to deal with is because a select few team members have most of the knowledge of the systems, and when these members leave, they take the knowledge with them.

However, there are ways to identify technical debt:

• Lean on inside knowledge: Survey your developers/engineers about the issues, as they may be aware of many of these within the system.
• Bugs and Root Cause Analysis (RCA): Technical debt often appears as unexpected issues or performance degradation. Analyzing the Bugs and RCA for patterns could lead to some great insights that can help uncover areas with large technical debt.
• Code analysis: Perform automated scans to identify design and implementation issues. A few of the tools that can be used to identify such issues in your Salesforce implementation are:
• – Static Code Analysis (PMD, SonarQube, etc.): Static code analysis tools can help you identify issues with code quality.
• – Salesforce Optimizer: Salesforce optimizer app that helps identify potential areas of concern within your Salesforce implementation.
• – Field Trip: Field Trip is an app-exchange tool that can help you identify unused fields and, to some extent, data quality issues.
• – Proactive Monitoring: Free with Premier/Signature Success offerings of Salesforce. Provides 24/7 monitoring of your crucial Salesforce solutions and helps you predict and prevent issues.
• – Org Health Assessment: Exclusive for Premier/Signature Success customers of Salesforce. In this 3-hour session, a Salesforce expert will guide you through the current challenges of your org and recommend some best practices to resolve them.
• – Org Check: A tool developed and maintained by Vincent Finet that allows you to perform a quick analysis of your org and helps you find those hidden technical debt items.

Step 2: Get buy-in from stakeholders
Once you have identified the technical debt and created quantifiable metrics to measure it, it’s time to present the finding to the stakeholders. Remember, technical debt impacts everyone, and it’s essential to get buy-in from the stakeholders. (Source: Pluralsight)

Step 3: Make addressing technical debt an everyday practice
Teams should make technical debt maintenance a daily or pre-sprint activity as part of the status quo. The assumption that 100% of the team’s time should be spent on shipping new features is often one of the primary root causes of having technical debt in the first place.

You need to allocate a budget in a way that says some percentage of this is always dedicated to maintenance, clean up, and bug fixing.

Step 4: Deploy a monitoring framework
Once you plan to reduce the existing technical debt, it’s a good idea to implement a monitoring framework to keep an eye on any new technical debt you might be introducing.

Step 5: Center of Excellence/ Change review
A Center of Excellence will allow you to have a formal strategy for managing change; it’s a baseline practice of governance that you can implement, no matter the size of your business. A CoE or review board will help you to ensure that all changes are vetted, and any potential technical debt you might be introducing is captured and planned. (Source: strongpoint.io)

Conclusion

Technical debt is a common challenge that many organizations face; there are many reasons why it occurs and how it morphs into this monster that starts impacting productivity and brings down the team’s morale.

Not all technical debt is bad, and neither does all technical debt require the same approach. Organizations must spend time to fully understand the impact of technical debt and how best to resolve it. Remember that managing technical debt is not a one-time activity. But it’s a journey worth taking.

References

– https://martinfowler.com/bliki/TechnicalDebtQuadrant.html
– https://medium.com/salesforce-architects/defining-identifying-and-measuring-technical-debt-5f783e2b381d
– https://en.wikipedia.org/wiki/Technical_debt
– https://en.wikipedia.org/wiki/Ward_Cunningham