Why technical debt is killing Salesforce agility

Managing technical debt in Salesforce is critical to maintaining its agility. In a recent McKinsey survey, CIOs reported that 10 to 20 percent of the technology budget dedicated to new products is diverted to resolving issues related to tech debt. More troubling still, CIOs estimated that tech debt amounts to 20 to 40 percent of the value of their entire technology estate before depreciation. This is mirrored in the Salesforce ecosystem where the speed of declarative development means that tech debt can build quickly.

In this article, we’ll explore why technical debt is a silent killer of agility, why it occurs, and strategies for avoiding it in the first place.  We’ll also look at some handy tools and strategies that accelerate getting technical debt under control. So let’s dive in.

Pssst: if you’re in a rush and want to get on top of technical debt quickly, Elements.cloud is the key to unlocking agility.

What is technical debt in Salesforce?

So, like most things, before we can manage it, we need to get a thorough understanding of what technical debt it is.  Technical debt occurs in nearly all software applications; it is not unique to Salesforce. Technical debt is incurred when technology infrastructure changes are not tracked.

Wikipedia: a concept in software development that reflects the implied cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer. As with monetary debt, if technical debt is not repaid, it can accumulate ‘interest’, making it harder to implement changes.

This is a limited view of why tech debt builds up in apps. There are several other good reasons why you have tech debt. And not all tech debt causes a problem. It is fine if it is an area of the app that is not being changed.

Let’s look at tech debt in financial terms as it needs to be repaid, and see how our behavior changes based on the interest rate for that debt:

High impact — Credit card: 29% APR

• Impact on current change projects.
• Increase in development times.
• Delay whilst a project refactors the debt.
• Affects Salesforce performance.
• Surprises/conflict causes release rollbacks.

Medium impact — Car loan: 5% APR

• Impact on future projects scheduled.
• Increase in development times.
• Delay whilst a project refactors the debt.

Low impact — Borrowing from family: 0.0% APR

• Limited or no changes project.
• No impact.

Causes of technical debt in Salesforce

Tech debt is unavoidable, and not all of it is bad. Tech debt can find its way into Orgs through several avenues, and some of these you will recognize. It’s important to note that not all tech debt is caused by poor design or shortcuts, as some sources suggest. Below are some common ways tech debt can arise:

• Change or outdated design: Tech debt can accumulate when business needs shift, rendering certain functionality unnecessary.
• New release: Tech debt can occur when new platform functionality supersedes features from prior releases or custom development. For example, PBW has been replaced by Flow, or Profiles/Permissions Sets.
• Deliberate: Tech debt can result from a deliberate decision to prioritize faster development, even if it means higher long-term costs. This is considered the right approach in some cases.
• Accidental: Tech debt can accrue when shortcuts are taken for various reasons, most commonly due to time constraints or multiple parallel workstreams.
• Poor analysis: A lack of documentation means that there is a poor understanding of how metadata is used, so it cannot be reused with confidence. So, instead, new metadata is created.
• Bolt-on: Tech debt arises when a particular functionality is repeatedly extended in increments and “bolted on” to keep it working, rather than being rebuilt properly.

Breakdown of factors contributing to tech debt

Here are some of the most common causes of technical debt encountered in Salesforce organizations. They are listed in the order of impact:

1. Lack of architecture design: If there is no consideration or planning of the technical architecture, then design decisions are made that lead to longer-term technical debt that is extremely costly to refactor. This is why Salesforce is devoting so much effort to developing architecture tools and resources.
2. No upfront security design: Again the security model needs to be designed to support the longer-term needs of the Org. A poor security design leads to additional work when any new functionality is developed, increased effort by the admins to manage user access, and potential security breaches. As we are seeing from the effort required to migrate away to the new Profile/Permission Set models, this has a high cost to rectify.
3. Insufficiently rigorous business analysis: Starting to build before you have understood the real requirements means that you run the risk of rework, where some of the original work is not used and is tech debt. It can also lead to poor architectural or security model decisions. 
4. Poor documentation: Failing to document customizations, processes, and code means that it is risky to reuse configurations. So, instead new functionality is developed potentially duplicating existing features. This is most often seen in fields and automations.
5. Excessive customizations: Over-customizing Salesforce beyond its standard configuration. Examples of this include creating custom objects when standard objects could suffice, which leads to unnecessary complexity. Custom objects might be designed with fields and relationships that don’t scale well or that duplicate functionality available in standard objects. This can result in a bloated Org that is harder to maintain and upgrade.
6. Unused managed packages: Unused packages that may have been installed for evaluation are often left in the Org. These need to be cleaned up, particularly if there is a cost.
7. Overly complex automation: Automations can rapidly become complex which makes them impossible to debug and reuse. Think about breaking them into smaller automations that can be triggered.
8. Complex sharing rules and roles: Overly complex sharing models and role hierarchies can make it difficult to understand and manage data visibility, leading to performance issues and maintenance challenges.
9. No formalized change management: No process of change management around the software development lifecycle (SDLC), can lead to poor architecture design, and insufficient analysis.
10. Hard-Coded IDs: Using hard-coded IDs can lead to code that breaks in different environments and is hard to manage.
11. Lack of test coverage: Salesforce requires a minimum of 75% code coverage to deploy from a sandbox to production. However, meeting this requirement with poor-quality tests (not testing various scenarios, not asserting outcomes) can lead to technical debt.
12. Not leveraging Salesforce updates: Salesforce has three major releases a year. These lead to technical debt. Not keeping up with these updates and the new features they introduce, can result in missed opportunities for optimization and innovation.

Addressing technical debt in a Salesforce Org requires a strategic approach, including regular code reviews, refactoring, keeping up with Salesforce releases, and ensuring that all customizations are well-documented and aligned with business needs.

What is the effect of technical debt on ROI?

Technical debt in Salesforce can significantly impact the Return on Investment (ROI), increasing the total cost of ownership (TCO) in several ways. These are listed in order of importance:

1. Reduced agility: Technical debt can make it difficult to adapt to new business requirements or to take advantage of new Salesforce features and updates. This lack of agility can hinder an organization’s ability to innovate and stay competitive.
2. Slower feature implementation: When an Org has significant tech debt, implementing new features can take longer because developers must navigate and modify a tangle of poorly designed code or configurations. This delay can result in missed opportunities and prevent the organization from quickly responding to market changes.
3. Lower user adoption: If technical debt leads to a system that is slow or difficult to use, user adoption may suffer. Low adoption can undermine the value of the Salesforce investment, as the system’s benefits are not fully realized.
4. Reduced productivity: Technical debt can lead to a less efficient system with slower performance. This can reduce user productivity as they may have to wait longer for pages to load or for complex reports to run.
5. Increased maintenance costs: As technical debt accumulates, the system becomes more complex and harder to maintain. This complexity requires more time and resources to manage, which increases operational costs.
6. Higher risk of downtime: Systems burdened with technical debt are more prone to errors and outages. Downtime can be costly due to lost productivity and potentially lost revenue, especially if it affects critical business operations.
7. Increased training costs: A Salesforce Org with a lot of technical debt may require more complex workarounds and non-intuitive processes, which can increase the time and resources needed to train new users or developers.
8. Quality and compliance issues: Poorly maintained systems may lead to data quality issues, affecting reporting and decision-making. Additionally, if technical debt leads to security vulnerabilities, it can result in compliance issues and potential fines.
9. Cost of refactoring: Eventually, technical debt will need to be addressed, and the cost of refactoring can be significant. This cost includes not only the direct expenses of the development work, but also the opportunity cost of not investing those resources in new features or improvements.
10. Impact on customer experience: If technical debt affects the customer-facing aspects of the Salesforce Org, such as customer service portals or integrations with other customer service tools, it can lead to a poor customer experience and potentially impact sales and customer retention.

In summary, technical debt can erode the value of a Salesforce implementation by increasing costs, reducing efficiency, and limiting the organization’s ability to leverage the platform for competitive advantage. Proactively managing technical debt is crucial for maximizing the ROI of a Salesforce Org.

Heard enough, and want to get on top of technical debt quickly, Elements.cloud is the key to unlocking agility.

So, how do you know what technical debt you have?

Tools for managing technical debt in Salesforce 

Managing technical debt in Salesforce can be made more efficient with the assistance of various tools designed to analyze, manage and minimize tech debt accumulation over time. For example, Salesforce Optimizer, an in-built Salesforce tool, provides reports on how you can improve and optimize your Salesforce Org – useful for tackling tech debt.

While Salesforce’s native tools give a good overview, to be able to really understand the level of tech debt and understand how to manage it, you need to look to external applications. They provide far more granular insights, analysis and management capabilities.

Elements.cloud provides a comprehensive platform that supports business analysis, architecture and change management processes. So it supports the different aspects required for the proactive management of technical debt. It offers a detailed analysis into the use and dependencies of metadata items. These insights combine to provide a view of the complexity and the impact of changes.

Elements.cloud also automatically generates metadata documentation and allows teams to easily create documentation. This approach ensures that Salesforce implementations are not only well-maintained, but also strategically aligned with business processes, ensuring scalability and efficiency.

By leveraging both Salesforce’s native tools and third-party solutions like Elements.cloud, organizations can effectively manage their technical debt, ensuring that their Salesforce Org remains a robust and strategic asset that continues to deliver value over time.

Processes for managing technical debt in Salesforce

So, knowing what technical debt we have, how do we clean it up? Addressing technical debt in a Salesforce environment involves implementing a structured approach that includes a series of steps and best practices to enhance the system’s health and maintainability. Also, ensure that any changes being introduced, genuinely add value and are ‘the right thing,’ so tech debt is not added by design. Here are some more tips:

1. Identification and assessment
   • Conduct a thorough review of the Salesforce Org to identify areas of technical debt. 
   • Use Elements.cloud in conjunction with Salesforce’s built-in tools like the Salesforce Optimizer, to achieve this. 
   • Document all findings and categorize them based on severity and impact on the business. Using Elements.cloud’s optimizer tab against any metadata item makes this a breeze.
2. Prioritization
   • Prioritize technical debt items based on factors such as user impact, system performance, security risks and alignment with business goals.
   • Consider the cost of delay for fixing each item and the benefits of resolving it.
   • Think about technical debt like a loan, as we mentioned earlier.
3. Planning:
   • Create a roadmap for addressing technical debt that includes timelines and resources needed.
   • Break down large items into manageable tasks.
   • Plan for refactoring within the context of regular development cycles, or as a part of dedicated sprints.
4. Documentation and knowledge sharing:
   • Update documentation during the analysis and the refactoring process.
   • Elements.cloud can automatically create documentation and highlight changes.
   • Share knowledge and best practices with the team, to prevent the accumulation of new technical debt.
5. Refactoring and remediation:
   • Rearchitect the data models, integrations, and security models to ensure the structure can support you in the long term.
   • Re-engineer processes to reduce complexity, such as consolidating workflows, process builders, and flows, into more streamlined solutions.
   • Update data models and sharing settings to simplify the Org structure and improve performance.
   • Remove unused features, fields, and code to declutter the Org.
   • Refactor code to follow Salesforce best practices, such as bulkifying Apex triggers and classes, optimizing SOQL queries, and ensuring proper test coverage
6. Release:
   • Implement comprehensive testing for all refactored code and configurations, to ensure functionality remains intact.
   • Use sandbox environments for testing before deploying changes to production.
   • Engage end-users in testing when appropriate, to validate that business processes work as expected.
   • Use a version control system and a CI/CD pipeline for deploying changes to ensure smooth transitions and the ability to roll back if needed.
7. Monitoring and continuous improvement:
   • After deployment, monitor the system’s performance and gather user feedback to ensure the changes have the desired effect.
   • Elements.cloud can be used to capture end-user feedback inside page layouts.
   • Establish a process for continuous review and improvement, integrating technical debt considerations into the development lifecycle.
8. Change management:
   • Educate stakeholders about the importance of addressing technical debt and secure their buy-in for necessary changes.
   • Communicate regularly with the team and stakeholders about the progress and benefits of addressing technical debt.

The final word

Technical debt doesn’t need to be scary. With solid processes, foresight, and the right tools to hand, Salesforce technical debt can be tamed.

Let’s have a conversation about how you can manage technical debt.

References

• Most effective delivery teams spend 20 to 30% of their time on long-term improvements to the solution. (Amit Chaudhary’s What is Technical Debt?)
• Technical debt is a leading obstacle to innovation for nearly 70% of organizations and tech debt consumes 31% of IT budgets and requires 21% of IT resources to manage. (Protiviti’s Global Technology Executive Survey)
• CIOs reported that 10 to 20 percent of the technology budget dedicated to new products is diverted to resolving issues related to tech debt. More troubling still, CIOs estimated that tech debt amounts to 20 to 40 percent of the value of their entire technology estate before depreciation. (McKinsey survey)