Defining, Identifying, and Measuring Technical Debt
The aim of this series is to give a holistic approach to managing technical debt in Salesforce. After defining what technical debt is, describing its various types, and covering ways to identify and measure it, the series goes on to outline a plan for prioritizing and planning a way out of technical debt.
So, what exactly is technical debt?
The term technical debt was coined by Ward Cunningham in 1992 as an analogy to debt in the securities market. He explained:
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]
Steve McConnell, author of “Code Complete”, defined technical debt as we know it today:
A design or construction approach that’s expedient in the short term but that creates a technical context in which the same work will cost more to do later than it would cost to do now (including increased cost over time). [Source]
Technical debt, in other words, is a trade-off between the short-term advantage of meeting a release deadline and delivering quality, efficient, and optimal code. A little debt is acceptable; however, if left unchecked it can cost a great deal of time and money in the future.
Technical debt on Salesforce will typically involve one or more of these factors:
- Incoherent configurations. For example, different styles of approvals for similar business processes, or multiple email templates for essentially the same communication
- Excessive customizations: For example, writing a trigger when you can use Process Builder to achieve the same result, or creating a new custom object rather than tweaking the requirement to use standard objects
- Poor code quality: For example, writing unit tests to meet a coverage requirement rather than actually assert a valid result, writing the same Apex code multiple times rather than consolidating it in a shared helper, or using hard-coded variables rather than custom metadata
- Redundant cruft: For example, unused packages, inactive workflows, half-built validation rules, never-executed code, remnants of proofs-of-concept and prototypes, and other clutter that can accumulate if you let it
What are the types of technical debt?
For years, software development practitioners have sought ways to effectively classify and communicate technical debt.
In 2007, Steve McConnell suggested that there are two types of technical debt: intentional and unintentional. According to him, intentional debt is technical debt that one takes on consciously as a strategic tool. This is in contrast to unintentional debt, which he calls “the non-strategic result of doing a poor job.”
Martin Fowler took McConnell’s concept a step further and published what he calls the Technical Debt Quadrant . This quadrant groups technical debt into four categories based on both intent and context. Fowler says technical debt can be classified based first on intent: is it deliberate or inadvertent? It is then even further distinguished by whether it is prudent or reckless debt.
The paper Towards an Ontology of Terms on Technical Debt cites 13 distinct types of technical debt and a set of key indicators for each.
- Architecture debt. Refers to problems encountered in architecture — for example, violation of modularity — that can affect architectural requirements (including performance and robustness, among others).
- Build debt. Refers to issues that make builds more difficult and more time or resource consuming than necessary.
- Code debt. Refers to problems found in the source code that make it more difficult to be maintained.
- Defect debt. Refers to known defects, usually identified by testing activities or by the user, that the change control board agrees should be fixed, but have been deferred due to competing priorities and limited resources.
- Design debt. Refers to debt that can be discovered by analyzing the source code and identifying the use of practices that violate the principles of good object-oriented design (for example, very large or tightly coupled classes).
- Documentation debt. Refers to problems found in software project documentation, including missing, inadequate, or incomplete documentation of any type.
- Infrastructure debt. Refers to infrastructure issues that can delay or hinder some development activities.
- People debt. Refers to people issues — for example, expertise concentrated in too few people as a result of delayed training — that can delay or hinder some development activities.
- Process debt. Refers to inefficient processes, for example, processes for which the initial use case is no longer appropriate.
- Requirement debt. Refers to tradeoffs made with respect to the specific requirements the development team has to implement or how to implement them. Examples include requirements that are only partially implemented, or requirements that are implemented but not for all cases.
- Service debt. Refers to debt incurred by the need for web service substitution, which can be driven by business or technical objectives. The technical debt can span several dimensions related to selection, composition, and operation of the service.
- Test automation debt. Refers to the work needed to automate tests of previously developed functionality to support continuous integration and faster development cycles.
- Test debt. Refers to issues that can affect the quality of testing activities. Examples of this type of debt are planned tests that were not run, poor code coverage, or other known deficiencies in the test suite.
How can technical debt be identified and measured?
Since all platform changes are a result of fulfilling business needs, it is important to be able to tie each solution to its ongoing need when identifying technical debt. To do this, it can be useful to ask the following questions.
Business questions
- Was the solution for a long-term or short-term requirement?
- Was the solution built to support a process that should be redesigned or otherwise improved?
- Was the solution built to achieve 100% of the requirement, when out-of-the-box functionality could achieve, say, 85%+ of the requirement?
- Was the solution built for a specific team with few users?
- Is the ROI of the solution greater than the cost of maintenance?
- Has a new product enhancement been released (or announced) that would render the current custom solution unnecessary?
- Does the business need still exist? Is the solution still actively being used by end users?
Technical questions
- Have other teams built similar solutions for similar needs? If so, can they be condensed into one solution or into less complex solutions with shared maintenance?
- Are there inconsistent user experiences for the same processes?
- Are solutions following the same reusable frameworks?
- Are solutions built following best practices?
- Are deployments or package validations taking too long?
- Are limits being exceeded, or are users seeing errors for SOQL, DML Row locks, API calls, or CPU time limits?
This is not an exhaustive list. Rather it is meant to help identify potential technical debt, along with disparities between the initial and ongoing reasons for the solution. Often, it is easier to revisit decisions if the need for a solution and its requirements are well-documented upfront.
After initial business requirement exploration, tools and services can help with additional identification and assessment of the technical debt:
Conclusion
Technical debt, or any solution that buys a short-term benefit at a potential long-term cost, is a common challenge that many organizations face. No system in use is completely free of technical debt, since no single technology or process is completely future-proofed. Technical debt begins to accrue the moment a system is implemented.
Not all technical debt is the same, however, nor does all technical debt require the same plan of attack. As systems mature, technical debt should be identified and scoped to determine its impact. Through regular process review and maintenance, technical debt is manageable.
Join us for the next part in the series, which outlines a plan for prioritizing and digging out of technical debt.
About the authors
Ankit Garg is a Technical Architect at Salesforce and has 13 Salesforce certifications. He has more than 11 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, as 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.
