Strategies to reduce Tech Debt

Written by Ian Gotts

Wikipedia: a concept in software development that reflects the implied cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer. As with monetary debt, if technical debt is not repaid, it can accumulate ‘interest’, making it harder to implement changes.

Wikipedia

The conventional wisdom is that technical debt, or tech debt, is a negative thing and development teams should strive to eradicate it. The (incorrect) view is that it is because tech debt is typically caused by poor decision-making. Whilst this may be true in some cases, it is not always true.

Tech debt is an inevitable result of agile systems that evolve to support constantly changing business needs. As organizations accelerate their digital transformation plans in order to accommodate hybrid working and respond to market forces, the systems that underpin their operations need to change. This often leads to tech debt. Additionally, Salesforce is investing heavily in its platform, so customer functionality that was previously developed in-house may now be integrated into the core platform, making existing configuration unnecessary.

It’s worth noting that not all tech debt is necessarily negative. While some tech debt may delay projects by making it more difficult to implement changes or requiring its removal prior to implementation of new projects, other tech debt may be acceptable. For example, if it exists in an area of the organization that rarely changes, its impact may be limited. Or if it is functionality that will have a limited life. For example an app for an event which is only going to be used once.

If it ain’t broke, don’t fix it

The main challenge lies in the fact that the levels and critical areas of tech debt are not well understood in many (if not most) organizations. As a result, it becomes incredibly challenging to accurately estimate and plan for changes with any level of certainty. Projects can encounter unexpected tech debt, leading to delays in release timelines. Alternatively, organizations may have to undertake a separate tech debt clean-up project that halts all future changes until it is resolved.

Not all technical debt is equal

Tech debt can find its way into orgs through several avenues, and some of these are likely familiar. It’s important to note that not all tech debt is caused by poor design or shortcuts, as some sources suggest. Below are some common ways tech debt can arise:

• Change or outdated design: Tech debt can accumulate when business needs shift, rendering certain functionality unnecessary..
• New release: Tech debt can occur when new platform functionality supersedes features from prior releases or custom development. For example, PBW being replaced by Flow.
• Deliberate: Tech debt can result from a deliberate decision to prioritize faster development, even if it means higher long-term costs. This is considered the right approach in some cases.
• Accidental: Tech debt can accrue when shortcuts are taken for various reasons, most commonly due to time constraints or multiple parallel workstreams.
• Bolt-on: Tech debt arises when a particular functionality is repeatedly extended in increments and “bolted on” to keep it working, rather than being rebuilt properly.

So how should we evaluate tech debt?

Let’s look at tech debt in financial terms as it needs to be repaid, and see how our behavior changes based on the interest rate for that debt:

High impact — Credit card: 29% ARR

• Impact on current change projects
• Increase in development times
• Delay whilst a project refactors the debt
• Affects Salesforce performance
• Surprises/conflict cause release rollbacks

Medium impact — Car loan: 5% ARR

• Impact on future projects scheduled
• Increase in development times
• Delay whilst a project refactors the debt

Low impact — Borrowing from family: 0.0% ARR

• Limited or no changes project
• No impact

How to reduce tech debt

To begin reducing tech debt, it’s crucial to have a comprehensive understanding of your org’s configuration in order to accurately categorize it. This is a foundational step in mitigating project risks. Elements.cloud constructs a metadata dictionary and analyzes the org to create a map of dependencies, impact and field population. It also identifies clean-up recommendations. To ensure you’re working with the most current information, it is updated on a nightly basis.

You need to have a complete picture of the org metadata and analysis, as an incomplete view of the metadata makes informed decision impossible. Relying on an outdated spreadsheet dump of org metadata, a list of some metadata dependencies using the Dependency API (DAPI), or a list of fields without any analysis is not enough.

Once armed with an understanding of the project scope and the complexity of the org in the area the project affects, you can assess the level of tech debt and determine the best strategy for reducing it. Below is a recommended approach that considers the type of debt and its level of impact.

How teams can impact technical debt

Here are some suggestions on how you can reduce the accumulation of technical debt and minimize existing debt:

• Ask the right questions: Work with business analysts to question every requirement, change, and specification. Ensure that developers are building the right product to reduce rework and enhance adoption. It’s vital to be aware that every change made is metadata that could be difficult to delete later on. Architects should be proficient in the implementation lifecycle and business analysis tools like UPN process mapping and live user workshops.
• Great data design: Ensure that the data model has been designed with performance, scalability, security, integration, and agility in mind. This may require time and a balance between short and long-term objectives. Poor decisions on data design can be very expensive to fix or even result in the need to discard the entire org and start over. A core skill for an architect is good ERD modeling analysis.
• Write it down: Documentation is essential. Poor documentation is the leading cause of tech debt. If metadata doesn’t include information on why it was created, where it is used, and who the stakeholders are, it’s tough to modify, deprecate, or delete. This results in adding new metadata that is often very similar to the existing one, resulting in an accumulation of debt. Salesforce has released the Salesforce Diagrams standard for ERD, System Landscape, Integration Layer, and User Provisioning and Deprovisioning Flow Diagrams to help address this issue. It complements the UPN standard for process mapping, requirements, and user stories.

Final word

Many organizations are held back by the accumulation of technical debt, which makes it difficult for them to be adaptable and nimble. To tackle this problem, it’s essential to have a full understanding and analysis of the org and prioritize areas with the highest level of technical debt. All team members play a crucial role in managing technical debt by taking it into account when making design decisions and creating clear documentation.