Tag Archives: governance

Managing technical debt in Salesforce

Managing Technical Debt in Salesforce

Deploy releases faster—and boost your Salesforce ROI 

What to know:

  • Bad technical debt impedes your release process and the health of your orgs—hindering your ability to conduct business. 
  • Good tech debt allows you to release changes faster—making you more agile and more responsive to opportunities.
  • Almost 75 percent of businesses that report a very high ROI from Salesforce have a continuous or fast release cycle.
  • Leveraging an agile approach to change management in Salesforce allows you to detect and address problems early on in the project while releasing incremental changes faster.

What Is Technical Debt?

There are two kinds of tech debt in Salesforce:

  • Bad tech debt is the cost of rework resulting from a rushed development process with siloed participation from team members—instead of using a better approach that would take longer to develop. 
  • Good technical debt pertains to the amount of work you need to invest now or in the future to ensure a streamlined, continual process that yields good results.

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. 

The Cost of Bad Technical Debt

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.

What Causes Bad Tech Debt?

Bad technical debt can be caused by several factors, including:

  • A lack of ongoing data model design and refactoring resulting from not having an established process to create new and update existing data models.
  • An over-reliance on programmatic customization, or worse: by poorly-written Apex and Visualforce pages causing bugs that can slow processes down and even crash your org.
  • Leveraging bad coding practices when there are readily available configuration options.
  • Poor data quality that leads to failed deployment and app crashes.
  • Irrelevant integrations that are performing actions you’re not even aware of.
  • Letting good tech debt build up for too long.

How to Minimize Bad Technical Debt 

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. 

The Value of Good Tech Debt

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 percent of study respondents with very high ROI from Salesforce have daily or continuous release cycles. In contrast, only seven percent of those with quarterly, bimonthly, or monthly release cycles cite a very high ROI.

How to Ensure Good Technical Debt 

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. (Read more in The Ultimate Guide to Salesforce Release Management.)

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:

  • Promote collaboration and coordination to implement uniform processes team-wide for data model design and refactoring.
  • Avoid over-customization resulting in bad code that doesn’t pass Salesforce’s minimum validation threshold to promote your changes.
  • Leverage available “clicks, not code” configuration when possible to avoid unnecessarily adding code that could adversely impact processes.
  • Keep data and validation rules up to date to prevent delayed processes or even downtime.
  • Regularly review integrations and managed packages, and make a plan to decommission old, unnecessary integrations out of your org. 
  • Adhere to a policy that documents all changes to an org so you have a history of modifications you can refer to in the event you need to troubleshoot. 

Prodly DevOps for 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 percent and deploy metadata 12 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.

To learn how your business can benefit from the Prodly suite, request a demo

The Value of Bidirectional Sandbox Seeding

In this blog, we explore what bidirectional sandbox seeding is and why you need it. We also look at the value of sandbox seeding with Prodly Sandbox Management, as well as why you should be seeding sandboxes in the first place.

What Is Bidirectional Sandbox Seeding?

Bidirectional sandbox seeding involves deploying data from your production org to a sandbox—and from your sandbox to another environment. You can do this with a freshly created org or during an environment refresh.

A photo of a desert with a traffic sign with arrows pointing in opposite directions representing bidirectional sandbox seeding

Why Do You Need Bidirectional Sandbox Seeding?

Bidirectional sandbox seeding allows you to create a fresh sandbox, deploy data to it, and then move data in any direction—up, down, and laterally. You can roll back changes to start all the way at the beginning, or you can change just one tiny detail. 

This makes for a much better auditability of changes in production and deployment results, resulting in better governance.

When you’re only able to work with partial data, the chance of bugs and errors slowing down your progress is immense. Many teams lose steam in the development and QA process when they go the route of manually working with a sandbox test data set. 

In contrast, bidirectional sandbox seeding gives control to anyone who can click through a data management workflow. 

The Value of Bidirectional Sandbox Seeding With Prodly

With the sandbox seeding feature in Prodly Sandbox Management, you have the ability to move data in both directions—with just a few clicks. This allows you to maximize your team’s efficiency, transform your entire workflow, and improve your end-user experience. 

By using this low-code option for DevOps, you’ll soon be handling change requests like clockwork. 

Improve Your Governance Strategy With Prodly

The seamless, automated process for seeding sandboxes Prodly provides enhances your governance strategy. 

It increases org health, fights errors, and immensely improves efficiency. Here’s how:

Prodly Sandbox Management can help you move your data up, down, backwards and forward between your production org and sandboxes. 

It gives you the power to migrate data from up to five orgs simultaneously. This eliminates the need to depend on a Full Copy Sandbox to work from as you advance through changes. 

You can also configure data simulations, meaning that you can make changes without consequences. When you need to deploy complex data from a schema all at once, you don’t have to worry about complications anymore. 

Sandbox Seeding Without Prodly

Without the sandbox seeding feature in Prodly Sandbox Management, you’re literally left to your own devices having to use a barrage of tools to handle what Prodly does seamlessly. 

There’s the tedious process of using a data loader. The difficulty, duration, and mind-numbingness of the project can be compounded based on the size of your project. 

Some companies employ a third-party developer to manage their sandbox, which can become quite costly. 

In contrast, with Prodly, you can populate—and even anonymize— representative test data into as many as five orgs in just a matter of minutes. Prodly gives you more control of your data and processes, as well as a greater probability of aligning your team with the needs of your stakeholders for every project. 

Why Should I Seed Sandboxes?

There are several very good reasons to seed sandboxes. 

Without sandbox seeding, there’s a lack of representative production data in lower-level sandboxes that makes it harder to imagine, configure, and test changes. 

This problem becomes more complicated as changes move up the release pipeline and you need to keep all of the sandboxes in sync with production.  

However, sandbox seeding lets you provide everyone with their own development environment before they promote their changes to a shared QA org and ultimately production. This circumvents the problem of who’s doing what in a shared sandbox—plus, it reduces the odds of overwriting each other’s work.

It lets your team work faster and test more thoroughly. It also gives you more effective use of your expensive sandboxes.

In addition, when everyone has their own development environment with representative data, it’s much easier to find a good window of time to refresh your Full Copy or Partial Copy sandbox. And that in turn reduces the number of errors you encounter during the development process.

See Bidirectional Sandbox Seeding in Action!

Discover how easy and quick it is to seed sandboxes with Prodly Sandbox Management—watch the 25-minute webinar Ask a CSM: Bidirectional Sandbox Seeding.