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.”
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.
We need to bring something additional into the conversation: Salesforce org documentation. This is one of the three actions I share in this article, and I felt was worth mentioning here to give you context. A poorly documented org wastes time for any future development. Spending a few minutes documenting the ‘how’ and ‘why’ of, for example, a process builder, will save hours when doing the impact analysis for a future release – or in the worst case, saving your org from downtime when a change breaks the org (OrgConfessions is full of examples where this has happened).
Cutting the ‘Risk of Salesforce’
Forrester wrote a research paper called “Five ways to cut the risk of Salesforce”, within it, coining the term “[email protected] 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 [email protected] 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” – while technical debt cannot be completely avoided, it can at least be mitigated.
Tackle Technical Debt (Or Pay the Price)
Tackling technical debt is a challenge because it involves “delayed gratification”, as in: “I need to spend more time now to reap the benefits in the future”. Balancing that trade off, and measuring the future cost, is difficult – especially with the pressure from business users to get new functionality.
The ultimate price a business can pay is that, if technical debt gets so great, the call is made 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.
For most orgs the issue is technical debt slows down releases. The COVID pandemic has accelerated digital transformation, 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.
3 Actions To Tackle Technical Debt (You Can Take Today)
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
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.
If you are considering building a spreadsheet as your metadata dictionary you need to understand the effort required to keep this up to date so that it has any value at all (among other compelling reasons). 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”.
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. Some 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. Documentation standards
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.
Some simple examples are: 1) every metadata item that has a description field must be filled out on all new or changed metadata items before you release, 2) naming standards on metadata items so you don’t get duplicates, eg. “Shoe size” and “Size of shoe” 3) no development will be started before the analysis that allows you to create at least one user story.
Not All Technical Debt Is Killing Your Org
Technical debt is like the stuff piling up in your garage. There are some really important things in there, but you have no clue where they are and what you might break when trying to find them. On the other hand, there are things in the garage that have no value and are just creating clutter. Finally, there are things that are clutter, but aren’t getting in your way, they are simply taking up space but don’t necessarily need to be cleared up.
The trick is prioritizing the areas of technical debt that need to be cleaned up, and then making changes to the way that you develop Salesforce to mitigate the build up of future technical debt.
The Final Word
Salesforce is a very powerful platform, but as Forrester pointed out back in 2017, over zealous (or uncontrolled) development can rapidly kill innovation and agility.
I’ve shared simple first steps to tame technical debt. After this you need to build a more robust analysis process ahead of any development to ensure that you minimize technical debt. I know this is hard – it feels like you are wasting time on analysis when you want to get on and start developing; however, the hours spent in analysis will save days in development and rework.
Start taking steps to identify, prioritize and reduce technical debt. Your future self will thank you.