Salesforce Technical Debt: A fairy tale or reality ?

Photo by Martijn Baudoin on Unsplash

Howdy Trailblazers! Welcome to my first (and probably not the last) blog post about the world of Salesforce. Over the past four years, I’ve been weaving my way through the Salesforce ecosystem, and it’s been a journey full of vibrant experiences and learning that I’m excited to share with you.

In this blog, we’re going to take a deep dive into a topic that’s often whispered about but rarely tackled: Salesforce technical debt. An undercurrent in a river – always there, sometimes unnoticed, but definitely shaping the journey. We’ll explore what it really means, what’s the symptoms, and most importantly, how to navigate it without losing your way. Hold tight!

Think of building a Salesforce solution like packing for a trip. You can either pack in a rush, throwing things into your bag haphazardly, or you can take time to correctly fold your clothes and pack correctly your items.

If you pack in rush, you might get out the door and head to the airport quickly, but once your final destination reached, you’ll find your clothes wrinkled, your items hard to find, and you have probably packed useless clothes and forgot important stuff. In Salesforce, this is like rushing through a project – you meet the immediate deadline, but later, you find your work is disorganized, hard to understand, or not maintainable at all.

On the other hand, if you pack carefully, you might take a little longer to leave, but once you open your suitcase, everything is easy to find, and your clothes are ready to wear. In our context, this means taking enough time to plan and build your solutions properly. It requires more effort (and probably have a cost) upfront, but it saves you time and hassle in the long run because your system is well-organized and easier to maintain.

What I’ve described is what we commonly refer to as technical debt.

Spotting technical debt: key indicators from past experiences

Through my past experiences in Salesforce, I became adept at spotting signs of technical debt. We’ve all been there, we’ve all experience these telltale symptoms :

1. Quickfixes becoming permanent : Sometimes we provide a quick fix that is meant to be temporary, and for some reasons (financial or time constraints), we end up with it becoming permanent solution. As we continue building more elements around it, the quick fix becomes deeply integrated, making it increasingly difficult to replace.
2. No-code, no technical debt myth : In Salesforce, low-code, no-code developments are considered immune to technical debt, they are frequently left untested and unreviewed, based on the false belief that only code can create technical debt. Here’s an example of no-code technical debt you could find in your org : Inactive flows, validation rules, picklist values ; Hardcoded record type ids in flows ; Unused profiles, list views etc…
3. Lack of documentation : When there’s no documentation or it is outdated and it makes understanding the system challenging, it’s a bad sign as it may lead to poor implementation choices or redundant efforts, as team members may not have a clear understanding of existing developments or functionalities.
4. Feedback fatigue : When you constantly have negative comments or concerns about the existing developments (not only Apex) from your team members.
5. Complex code : Code so intricate, it could be its own puzzle. Or when a quick fix turns into a long journey where two thirds of the time was spent just understanding the code.
6. Performance issues : Frequent latencies or slow time responses on integrations, custom components or even simple record triggered automations means that there’s place for improvement and your system needs a doctor.

The symptoms we’ve discussed, like complex code leading to inefficient implementations, are crucial indicators of technical debt in Salesforce projects. However, recognizing these symptoms alone isn’t sufficient. To effectively communicate the impact of technical debt to stakeholders and all the concerned actors, we need concrete metrics.

Cue the metrics

In this part of the blog, we’re diving into the world of tools and techniques that’ll help us measure and showcase technical debt in hard numbers. When it comes to tools, there’s limitless of free and paid ways to identify your technical debt, here’s my favourite 5 :

1. Static code scanner : I personally use PMD for static code scanning for potential issues, threats and also to ensure that best practices are being followed.
2. Salesforce Optimizer : A native free Salesforce app that evaluates your Salesforce org, providing recommendations to optimize feature usage and simplify customizations. It’s particularly useful for identifying underutilized or outdated components in your org.
3. Org monitoring : You could use built in Salesforce monitoring to get metrics about your org overall performance, governance limits, storage etc…
4. Event monitoring : Paid Salesforce solution that helps you drill into your data and swiftly identify slow page performances, poor user adoption, metrics about exceptions and API usage etc…
5. Org Health assessment : The Org Health Assessment helps you check your system’s overall health and provides recommendations on how to improve it.

Photo by Towfiqu barbhuiya on Unsplash

Conclusion

As we wrap up this blog, it’s clear that the topic of technical debt in Salesforce is as vast and deep as the platform itself. While we’ve explored key symptoms, touched on the importance of recognizing technical debt, and discussed some essential tools to identify and manage it, there’s so much more to this subject than what can be covered in just one or two blog posts.

The most crucial step is recognizing its existence. Don’t stress about fixing everything at once; managing technical debt is a gradual process. Awareness is your starting point, and from there, you can steadily work towards solutions. Until my next blog, keep blazing trails!