Technical debt is the cost of additional rework caused by choosing an easy solution now instead of using a better approach that would take longer to develop. It’s also known as a concept called “Shift Left” – “the earlier you catch problems, the cheaper it is to fix them”.
Creating technical debt for your Salesforce system isn’t the end of the world – it’s an unavoidable necessity. Like any debt, pay it back and you’ll avoid the buildup of “interest” that will eventually kill agility.
Technical debt used to be a developer’s problem – when taking shortcuts with code – however, with low-code platforms like Salesforce, technical debt now appears as a result of “clicks”, as well as code.
Since originally writing about technical debt, it became apparent that Salesforce technical debt is often so severe that it needs to involve architects. This guide covers how Salesforce technical debt is everyone’s problem.
What Is Salesforce Technical Debt?
Technical debt is the cost of additional rework caused by choosing an easy solution now (built quickly and without a comprehensive understanding of the business requirements) instead of using a better approach that would take longer to develop.
Technical debt also can refer to solutions that were built to work one way, however, business needs have evolved over time (e.g. bolted on small tweaks).
The broad definition of technical debt is, whether code or declarative, the customizations previously made where standard functionality was not applicable or available.
A more helpful way to think about technical debt is that everything is technical debt. However, technical debt is called “debt” because it needs to be repaid. We can compare the levels of “interest” we pay on it:
Low interest, e.g. borrowing from family: 0.0% ARR.
Low impact, e.g. a Salesforce Flow that is doing what it should:
- Limited or no changes project
- No impact
Medium interest, e.g. car loan: 5% ARR.
Medium impact, e.g. an unused field that can’t be deleted because of its many dependencies (such as Apex triggers):
- Future projects scheduled would be impacted by this debt
- Increase in development times
High interest, e.g. credit card: 29% ARR.
High impact, e.g. a function you’ve tweaked 12 times in the past year and is throwing errors every couple of days:
- Impact on current change projects
- Increase in development times
- Delay whilst a project refactors the debt
- Affects Salesforce performance
- Surprises/conflict cause release rollbacks
If technical debt gets so great, the ultimate price a business can pay is to throw the org away and start again (and along with it the years of investment). This seems extreme but happens more often than you think.
What Causes Technical Debt?
There are several ways tech debt makes its way into orgs. Of these common causes, I’m sure you would have already anticipated at least a couple of them being featured:
- Changed or outdated design: When the business’ needs have changed and therefore functionality is no longer needed – but it’s safer to leave the functionality in.
- New releases: Occurs when new platform functionality supersedes features from prior releases or custom development. For example, Salesforce Flows, which are superseding process builders/workflow rules.
- Deliberate tech debt: When a conscious decision is made to speed up development with the clear view that it will be more costly in the long term, but this is considered the right path
- Accidental tech debt: Accumulates when shortcuts are taken for any number of reasons — most commonly because of time constraints or multiple parallel work streams.
- Bolt-on tech debt: Happens when a specific functionality keeps getting extended in increments and “bolted on” to keep it working, rather than rebuilding it properly.
Technical debt is a challenge because you need to make a trade-off between “delayed gratification” (“I need to spend more time now to reap the benefits in the future”) and measuring the future cost.
Examples of Technical Debt in Salesforce
Visualforce Component vs Sales Path
Prior to the release of Sales Path, companies needed a visual way to represent an opportunity stage/process. They would have to customize a Visualforce component to show the progress of an opportunity. Once Salesforce released Sales Path, those visualizations then became standard and, consequently, shot up the technical debt interest rate.
Adapting Process Automation
The founders of 10K realized that they needed to automate their invoice generation. They wrote an hourly function to generate invoices with some simple rules. However, as their contract structures evolved, additional functions were added to their once simple job. Changes became harder to maintain, so they carved out time to rewrite the job based on the then-current state of the business.
Tackle Technical Debt (or Pay the Price)
For most orgs the issue is technical debt slows down releases. Digital transformation has accelerated since 2020, meaning that the changes to Salesforce need to be far more responsive to enable the business to adapt.
“Speed and relevance are the most important currencies during a crisis. That means adapting quickly and leveraging technology” Source: ZDNet
There is a direct correlation between faster releases and greater ROI from Salesforce. Here are the findings from the “Project to Program” research report from 10K Advisors.
We’ve come across at least two organizations that were forced to put a freeze on all changes for 6+ months in order to get a handle on their tech debt. Without org impact and dependency analysis, these organizations likely would have “thrown” the org away – and started again.
Simple Actions To Tackle Salesforce Technical Debt
There are actions that you can take that will also drive benefits immediately. You will see some quick wins that will show the value to you and your senior management – so not everything has to involve delayed gratification!
1. Org Inventory (“Shelf Life”)
Do you know what is in your org? When was the last time you took an inventory?
You need a metadata dictionary that is kept in sync with all your orgs (production and sandboxes). This will give you analytics on where technical debt is hurting you most – which is different for every org.
You probably already feel the pain, but putting some metrics on it will help you build your case to invest in clean-up.
You could build a spreadsheet as your metadata dictionary, sure – but first understand the effort required to keep this up to date. Our team created an Org Discovery process which was aimed at anyone approaching a new org, but it is just as relevant as a “Technical Debt Discovery Process”.
From there, determine your customizations’ shelf-life before they’ll be considered stale. What works today won’t necessarily serve your organization’s needs next year, three years, etc.
2. Prioritize the clean-up
Use the metadata dictionary analysis to highlight the problem areas, where technical debt is slowing down development, causing org crashes or limiting your ability to use Salesforce features. Examples include maxed out field limits per object, overly complex Flows, massive numbers of record types on objects.
Use the metadata dictionary as the place where you document the optimization opportunities as you bump into them – even if they are not in a priority area, for example, unused fields, redundant page layouts, dashboards using out of date reports.
The big items are unused managed packages that might be costing you money; if you suspect this is the case for you, check out the MIME framework (Maximum Impact, Minimum Expense framework).
3. Minimum viable documentation
A poorly documented org wastes time for any future development. Spending a few minutes documenting the ‘how’ and ‘why’, for example, a Salesforce Flow, will save you hours when doing the impact analysis for a future release. In an extreme case it will save your org from downtime when a change breaks the org.
Let’s make it simple. You cannot go back and document everything that has happened in the past – but from now on, what is the minimum level of documentation that you must have before you are allowed to deploy a release? Before you release, not after. Agree some standards, for example:
- Every metadata item description field must be filled out on all new or changed metadata items before you release,
- Naming conventions on metadata items (so you don’t get duplicates), e.g. “Shoe size” and “Size of shoe”.
- Development cannot be started before the analysis that allows you to create at least one user story.
4. Build Team Consensus
Embrace that technical debt is inevitable and build consensus around it as a team.
You need to build time into your normal operations to evaluate and pay down technical debt. Every stakeholder, both business and technical, also needs to understand the current state of technical debt interest in your org.
Time and again, our work has revealed that the best way for any organization to systematically manage its technical debt is by establishing a Salesforce Center of Excellence.
Technical debt used to be a developer’s problem. The reality is that everyone using Salesforce contributes to technical debt, for example, Salesforce Admins, and even the marketing team!
Tackling Salesforce Architecture Technical Debt
The 2020 Salesforce Talent Ecosystem Report found that the YoY global demand growth for Technical Architects took a considerable hit. This may be indicative of organizations shifting away from long-term, strategic focus in favor of quick win customizations and add-ons. This can, unfortunately, result in an accumulation of unmanageable technical debt over time.
Simultaneously, the global demand for developers outpaced architects.
How does this indicate a risk of incurring more technical debt? One of the easiest ways to envision the architect/developer relationship is considering what it takes to build a house. Without an architect designing the blueprints and final configurations from the onset, the house being built will be riddled with issues to be dealt with at some point in the future–wasting both precious time and money.
The real issue is that, in most Salesforce orgs, the hotspots causing technical debt are not understood. Changes are scoped – with a low level of confidence – and then the release is delayed as the tech debt is encountered. For example, a separate technical debt clean up project that stops all future changes.
The architect can influence technical debt in the design decisions they make and the documentation that they create – but only with complete org understanding and analysis.
There are three ways that architects can reduce technical debt – both its build up and existing debt reduction.
1. Enhanced documentation
Building on the short-term advice to create an “org inventory”, a metadata dictionary is used to analyze data and to create a map of field population and dependencies. This should be updated at the close of every working day so everyone is working with up to date intelligence. At Elements, we’ve synced and analyzed over 10 billion metadata items.
If metadata does not have why it was created, where it is used and who are the stakeholders then it is very difficult to change, deprecate or delete. So instead new metadata is added, often which is very similar to the existing metadata. Until it goes on, release after release, year after year.
There is hope. Salesforce has released the Salesforce Diagrams standard for ERD, System Landscape, Integration Layer and User Provisioning and Deprovisioning Flow Diagrams. This complements UPN standard for process mapping and also requirements and user stories.
2. Question every requirement
Teamed up with the business analysts, architects need to question every requirement – every change, and every specification. There are clear benefits in reduced rework and improved adoption. But there is also the issue that every change that is made is more metadata that is difficult to delete with confidence.
Architects need a good understanding of the implementation lifecycle and the business analysis tools and techniques such a UPN process mapping and facilitating live user workshops.
3. Data design
Ensure that the data model has been designed with performance, scalability, security, integration and agility in mind. This may take time and need to balance short and long term objectives. However, we see orgs that have made snap decisions on data which have proven to be prohibitively expensive to fix or even fatal. For example, enabling person accounts.
Good ERD modeling analysis is a core skill for an architect and there are training courses and a Salesforce standard.
Summary: Cutting the ‘Risk of Salesforce’
Forrester wrote a research paper called “Five ways to cut the risk of Salesforce”, within it, coining the term “Salesforce@scale dilemma”. They identified the build up of technical debt in an org that clogs up its arteries, and eventually kills the agility:
“In addition, the complexity of scale crushes Salesforce’s responsiveness. As Salesforce use grows, innovation slows and flexibility evaporates. Why? Every app change risks breaking one of hundreds of data and process customisations, integration links, and third-party add-ons. The result: every change requires long and expensive impact-analysis and regression testing projects – killing the responsiveness that made Salesforce attractive at the start.
The Salesforce@scale dilemma is a challenge for clients to overcome, rather than an inevitable outcome of large-scale, strategic Salesforce implementations. It is a big issue because Salesforce has become a much more strategic supplier in technology strategies to win, serve and retain customers.”
The good news is (as Forrester says) that this is a “solved problem”. Technical debt isn’t a bad word, so it should be discussed, budgeted for, and planned for. It’s no secret that Salesforce is constantly evolving, as is your business and its processes, so why not plan ahead and avoid the surprise?
Comments: