What to know:
There are two kinds of tech debt in Salesforce:
In this blog post, I’ll examine the cost of bad tech debt, what causes it, and how to fix it. I’ll also discuss the value of good tech debt and how to ensure it.
Picture the following scenario: In your prod org, there’s a custom object that’s… well, let’s just say it’s delicate. Every time you need to add a new item or delete a custom field, you run into problems that slow down processes—or worse, crash the org. As a result, nobody wants to touch the object. And that affects your ability to fulfill requests and obstructs your business process.
This is an example of bad technical debt that’s most likely the result of not investing sufficient time in the steps needed to achieve a clean process. And it’s understandable, considering it’s often challenging to balance priorities when you’re constantly under pressure from users to provide new functionalities.
Unfortunately, when bad technical debt becomes too great, it significantly delays releases. In some cases, businesses wind up throwing the org in question away and starting over from scratch. Either way, it’s detrimental to your business’s responsiveness—not to mention frustrating for your team and users.
Bad technical debt can be caused by several factors, including:
You can minimize bad tech debt by trying not to incur it in the first place. It may be tempting to jump straight to Apex to solve a problem, but don’t overlook long term maintenance costs of custom code solutions. Instead, push Salesforce’s point-and-click solutions to the limit, as the maintenance cost of supporting falls to Salesforce—not you.
If you do find yourself buried in technical debt, it’s possible to dig yourself out. First, you’ll need to understand the scope of the debt. Start with an org audit, and use tools like Salesforce Optimizer, Field Trip, or Metazoa to go faster. I find it helpful to go object by object, starting with the most commonly used ones. Old record types? Fields that are not being used? Validation rules whose origin you can’t trace? Mark it all down. The goal at this stage is just to get a clear picture of what’s going on.
Next, figure out a plan of attack. It’s not possible to fix everything at once, so address issues in order of importance. What’s causing the most impact to users or breaks most often? What’s the biggest blocker to passing code coverage?
Be prepared—tech debt can be a tangled mess. Pulling on one thread may mean you need to unravel a few others. Don’t be discouraged. Steadily making progress on reducing tech debt will pay off. And when you’re most frustrated, knock out a couple of your pet peeves. (Mine? Page Layout sprawl).
Finally, establish policies and processes to prevent your org from winding up in this state again. That should include setting standards for documentation. Your future self will thank you.
Let’s say you want to roll out a new flow for your users. Now, you could create a plan that requires you to get the complete flow with all its bells and whistles up and running in a few weeks—but the chances of bugs and errors due to going too fast are very high.
So instead, you design a project plan that includes the steps to initially build and deploy the basic flow, and then add additional features once that’s live. The plan gives your team sufficient time to complete each step, work out the bugs, and get each new iteration up and running so your users are happy and the flow drives increasingly more value for your business.
As this example shows, the value of good tech debt is that it enables faster releases—which in turn yield greater ROI from Salesforce. Research shows that 73% of study respondents with very high ROI from Salesforce have daily or continuous release cycles. In contrast, only 7% of those with quarterly, bimonthly, or monthly release cycles cite a very high ROI.
Good tech debt in Salesforce comes from leveraging the iterative process of agile. As we’ve seen, fast release cycles drive Salesforce ROI—but velocity shouldn’t come at the expense of org health.
You should optimize your release management practices to minimize bugs and errors that result from cutting corners in the name of speed. Leveraging an agile approach to change management allows you to detect and address problems early on in the project while releasing incremental changes faster.
So you need to build out an initial project, release it, and—critically—complete optimizations plus add additional features later. Note that if you don’t complete your backlog, you’re building up bad tech debt.
Keep these tips in mind to ensure good tech debt:
You can also leverage automation to help ensure good tech debt. The Prodly suite includes the next-gen DevOps solutions Prodly Sandbox Management and Prodly DevOps. They enhance and streamline change management in Salesforce by automating data and metadata migration, sandbox seeding, and sandbox management.
Because these solutions eliminate manual labor in data and metadata migration, they’re 100% accurate, which minimizes rework due to errors and bugs. They reduce data migration time by up to 85% and deploy metadata 14 times faster than change sets. As a result, you gain more time for higher-level work, which enables you to ramp up your release cycles—and drive your business forward.
What to know:
There are two kinds of tech debt in Salesforce:
In this blog post, I’ll examine the cost of bad tech debt, what causes it, and how to fix it. I’ll also discuss the value of good tech debt and how to ensure it.
Picture the following scenario: In your prod org, there’s a custom object that’s… well, let’s just say it’s delicate. Every time you need to add a new item or delete a custom field, you run into problems that slow down processes—or worse, crash the org. As a result, nobody wants to touch the object. And that affects your ability to fulfill requests and obstructs your business process.
This is an example of bad technical debt that’s most likely the result of not investing sufficient time in the steps needed to achieve a clean process. And it’s understandable, considering it’s often challenging to balance priorities when you’re constantly under pressure from users to provide new functionalities.
Unfortunately, when bad technical debt becomes too great, it significantly delays releases. In some cases, businesses wind up throwing the org in question away and starting over from scratch. Either way, it’s detrimental to your business’s responsiveness—not to mention frustrating for your team and users.
Bad technical debt can be caused by several factors, including:
You can minimize bad tech debt by trying not to incur it in the first place. It may be tempting to jump straight to Apex to solve a problem, but don’t overlook long term maintenance costs of custom code solutions. Instead, push Salesforce’s point-and-click solutions to the limit, as the maintenance cost of supporting falls to Salesforce—not you.
If you do find yourself buried in technical debt, it’s possible to dig yourself out. First, you’ll need to understand the scope of the debt. Start with an org audit, and use tools like Salesforce Optimizer, Field Trip, or Metazoa to go faster. I find it helpful to go object by object, starting with the most commonly used ones. Old record types? Fields that are not being used? Validation rules whose origin you can’t trace? Mark it all down. The goal at this stage is just to get a clear picture of what’s going on.
Next, figure out a plan of attack. It’s not possible to fix everything at once, so address issues in order of importance. What’s causing the most impact to users or breaks most often? What’s the biggest blocker to passing code coverage?
Be prepared—tech debt can be a tangled mess. Pulling on one thread may mean you need to unravel a few others. Don’t be discouraged. Steadily making progress on reducing tech debt will pay off. And when you’re most frustrated, knock out a couple of your pet peeves. (Mine? Page Layout sprawl).
Finally, establish policies and processes to prevent your org from winding up in this state again. That should include setting standards for documentation. Your future self will thank you.
Let’s say you want to roll out a new flow for your users. Now, you could create a plan that requires you to get the complete flow with all its bells and whistles up and running in a few weeks—but the chances of bugs and errors due to going too fast are very high.
So instead, you design a project plan that includes the steps to initially build and deploy the basic flow, and then add additional features once that’s live. The plan gives your team sufficient time to complete each step, work out the bugs, and get each new iteration up and running so your users are happy and the flow drives increasingly more value for your business.
As this example shows, the value of good tech debt is that it enables faster releases—which in turn yield greater ROI from Salesforce. Research shows that 73% of study respondents with very high ROI from Salesforce have daily or continuous release cycles. In contrast, only 7% of those with quarterly, bimonthly, or monthly release cycles cite a very high ROI.
Good tech debt in Salesforce comes from leveraging the iterative process of agile. As we’ve seen, fast release cycles drive Salesforce ROI—but velocity shouldn’t come at the expense of org health.
You should optimize your release management practices to minimize bugs and errors that result from cutting corners in the name of speed. Leveraging an agile approach to change management allows you to detect and address problems early on in the project while releasing incremental changes faster.
So you need to build out an initial project, release it, and—critically—complete optimizations plus add additional features later. Note that if you don’t complete your backlog, you’re building up bad tech debt.
Keep these tips in mind to ensure good tech debt:
You can also leverage automation to help ensure good tech debt. The Prodly suite includes the next-gen DevOps solutions Prodly Sandbox Management and Prodly DevOps. They enhance and streamline change management in Salesforce by automating data and metadata migration, sandbox seeding, and sandbox management.
Because these solutions eliminate manual labor in data and metadata migration, they’re 100% accurate, which minimizes rework due to errors and bugs. They reduce data migration time by up to 85% and deploy metadata 14 times faster than change sets. As a result, you gain more time for higher-level work, which enables you to ramp up your release cycles—and drive your business forward.