Technical debt, also known as Tech debt, is the data that hangs out in our Salesforce environments. Most of the time it’s fairly harmless, but when it causes a problem it can do so in a big way. Today, let’s talk about technical debt, what it is, the why we avoid it, the different types, and what we can do about it. 

As a quick side note, many of the categorizations done in this article are not listed from an official definition document. Instead they have emerged as trends from user experience. If you know them by another name, please leave a comment so we can stay on the same page. 

What is Technical Debt?

Technical debt are the remnants we leave in Salesforce that do not contribute to the current business goals. As we build in Salesforce we may get a request to add a field, or report, or automation that solved a temporary need, but things changed and the thing we built just lingers in the system. The code that we commented out. The workflow rule we just turned off. The field we removed from the page layout. All of these hang out in the system and for the most part we remember what they are and that they are not needed so we don’t bother to get rid of them. 

Why do we avoid Technical Debt?

The simple answer: it’s not flashy. When we complete a technical debt cleanup there is nothing for the end users to really see. These were all the things the business wasn’t seeing. It’s really hard to justify budget for making something stop existing and that we can’t show off when we are done. Afterall, what value is there to spending time to research, review and risk removing something that no one saw anyway?

Well, the hard reality is the longer we leave technical debt in our system the greater the probability the following will happen:

1. We build something that interacts negatively with it

2. Our familiarity with it gets less and less and we are more afraid touching it will break something

3. Our teams change and we lose the people who know what it does

4. It’s referenced by so many things it becomes impossible to unwind easily

Get a bunch of Salesforce professionals together and they can tell you, technical can rack up hundreds of thousands of dollars of loss very quickly. It also slows development down substantially in the short term as well. A rousing round of who built this, can I modify it takes time and increases frustration quickly.

At the end of the day all of the risks of technical debt seem in the far off future, and we need to deliver features now.

The Different Types of Technical Debt

Programmatic Technical Debt

On the other side of those clicks is the code based side of Salesforce. Salesforce allows us to customized in countless ways and when we need something special we go to code. Code is the hardest form of technical debt: it can be hard to understand, is frequently entertwined and is the hardest to quantify.

What Do We Do About Technical Debt?

Technical Debt often feels like a huge undertaking that has no guaranteed pay out at the end, but by now I’m hoping you’re at least willing to check out some of the strategies for dealing with it. 

Find the Rhythm

Having a pristine org sounds great, but tackling it all at once is a fast way to drive yourselves nuts. Establish pattens of review: when do we review workflow rules, when do we review flows. Stagger them so we’re asking for yes or no on a few items at a time. Bonus: when you go to delete them much lower risk on not knowing where a bug came from. 

Phase it Out

If you think something isn’t being used but you can’t quite be sure (example: reports) put it somewhere users won’t be able to access it. Set a clock and if no one has asked after a certain amount of time proceed with deleting. 

Evaluate Early, Evaluate Often

Especially useful in code, check in on whether or not there the code is clear. Did the complexity of this code require it to be a higher story point value. Once it takes more story points to understand the legacy code than to add to it, it’s time for an optimization story to go to the backlog. 

Net It Out

When working with end users or Business Analysts that ask for a lot of customization, setting a precedent of netting it out can be extremely valuable. If they ask for a new field, have a report that shows the fields with the lowest values and ask if any of those should be eligible for backup and deletion. When fields are used less than 1% of the time it’s likely there is a training concern, a data validation concern, or the field isn’t bringing a whole lot of value to the table. 

Build for Scale

Finally, when designing for Salesforce try to avoid solutions that only solve one problem. If one team is asking for a field, determine how others might benefit from it. Or is there something existing that could be expanded to support multiple teams. Not everything will scale, but keeping it in mind during design can help prevent technical debt before it starts. 

Technical debt will likely remain a hidden monster for while to come, but we want to hear from you on how you deal with it. Please share any tips/tricks/tools in the comments.

Hope to see you around the groups or at the very least see you on the trails.