It’s usually the case that technical debt is placed in the “important, but not urgent” quadrant, with many organizations failing to prioritize technical debt remediation projects. This is because these projects don’t deliver immediate commercial results and are typically pushed by technical teams, not business stakeholders. However, this perspective is short-sighted; the benefits of addressing technical debt are long-term and include lower maintenance costs, greater agility, faster time to market, and improved performance.
All these factors have a significant impact on the business outcomes of an organization. In this article, we’ll first explore what technical debt looks like in the context of Salesforce and then analyze the impact of AI tools. On one hand, AI has the potential to help address technical debt; on the other, it could actually increase it. Let’s take a closer look at both sides.
What Is Technical Debt?
Technical debt refers to the long-term consequences of decisions made to accelerate development or meet short-term goals at the cost of future maintainability, scalability, and performance.
In Salesforce, technical debt can accumulate in various ways – Here are the most common ones that occur.
The Proliferation of Custom Fields and Custom Objects
Due to a lack of expertise or visibility, delivery teams may create custom objects and fields that aren’t truly necessary.
This can happen when there are existing objects or fields that already serve the same purpose, or when new fields are created for temporary, short-lived use cases, like a one-off online form.
The “clean-up” process never gets prioritized and some of these fields and objects remain in the Org dormant, with no data, duplicated data, or irrelevant data.
The Proliferation of Flows/Processes
A lack of a standardized approach to automation can lead to an abundance of flows (and Process Builder processes, despite no longer being supported).
Teams create new flows without analyzing whether an existing flow could be modified. Sometimes, these flows contain entire branches that are no longer relevant.
Outdated and/or Inefficient Code
There can be several reasons for this. Sometimes it’s simply due to a lack of skills within the development team, but more often, it results from the codebase evolving without back-propagating new frameworks and best practices, or checking if existing code could be repurposed.
Teams are often hesitant to modify code they didn’t originally build, especially if they aren’t given the necessary time and resources. This issue also applies to code that fails to adhere to best practices or standards.
ISV Packages That Are No Longer Maintained
It’s not uncommon to find some mysterious packages installed in an org, with no one knowing why they are there.
A common scenario is someone trying to uninstall these packages and being discouraged by some error messages – leaving them there, unused, for years and years.
Point-to-Point Integrations Bypassing the Company’s Governance Framework
I’ve encountered this scenario multiple times. When a new integration is needed, following the official process would require involving the company’s integration team, which is often overloaded with requests.
This creates a queue, and the integration team also enforces strict standards that must be followed. As a result, some internal teams decide to “go rogue” and set up their own point-to-point integrations, bypassing the official process.
It’s important to note that not all debt is equal. When planning remediation, you should analyze and prioritize the issues that are likely to be causing the most problems, not just currently, but also in light of potential future changes.
Will AI Help or Make Things Worse?
With the AI revolution unfolding, are we going to see more technical debt or will organizations benefit from AI capabilities to tackle the existing technical debt and prevent it in the future?
Let’s take a look at two common perspectives on this and explore both sides of the argument.
Argument 1: AI Will Increase Technical Debt
AI is speeding up development like never before, but is it setting us up for long-term challenges? Let’s take a look at how this might increase technical debt.
Codebase Accelerated Growth
AI-powered coding assistant tools driven by large language models (LLMs), such as GitHub Copilot, are rapidly making their way into software development environments. Generative AI has quickly become the go-to solution for speeding up development and operations across the board.
AI can write code quickly, but should this code be written in the first place? The increasing pressure on Salesforce delivery teams – particularly developers – to prioritize speed and to ship functionality ASAP is leading to shortcuts, and now these shortcuts can be generated by AI at light speed.
There is no time to take a step back and analyze if coding is actually the best solution.
Code Maintenance
There is yet another challenge when it comes to coding; GenAI tools might generate code that the developers don’t fully understand.
When a team of developers writes code ‘from scratch’ (without AI), they understand what they are creating. They hopefully write documentation about it and they can answer any questions or troubleshoot in case of errors. Even if they use AI for writing some parts of the code, they remain in control. They use AI to save time, not to replace their problem-solving skills.
On the other hand, there are scenarios where developers lean on GenAI to write the entire codebase or significant parts of it. In these cases, they often don’t have a deep understanding of how the code actually works. This can create several issues, such as difficulties troubleshooting when something goes wrong, and bugs or vulnerabilities being more likely to slip through unnoticed.
Over-relying on GenAI leads to technical debt, where the quick, AI-generated solutions might not follow best practices or be built to scale. Developers still need to stay in control by reviewing, refining, and understanding the code to ensure it’s solid and future-proof.
Declarative Tools and Generative AI
We might find similar challenges with declarative features (meaning clicks not code) within Salesforce. With the upcoming release of Einstein for Flow (Beta at the time of writing), admins might choose to let AI create custom flows instead of evaluating whether an out-of-the-box feature could do the job.
Also, just as with code, we could see a proliferation of flows that admins or developers may not be fully familiar with, complicating maintenance and troubleshooting.
Degradation of Skills
Another concern is the potential loss of skills and knowledge from over-relying on AI. Before Generative AI, we had to fully understand not only the problem but also the exact steps to solve it before translating that solution into (for example) a flow or formula in Salesforce.
It could be frustrating (does anyone actually enjoy Formula syntax?), but the upside was gaining a deeper understanding of both the problem and its solution.
With the release of AI assistants like Einstein for Flow and Einstein for Formula, we might start delegating all logical thinking to AI (much like we did with calculators and arithmetic) without fully developing our own Salesforce skills.
If we turn to AI for solutions without having developed the technical skills to assess its suggestions, we risk unknowingly implementing poor or unsuitable solutions.
Proliferation of Tools
At the time of writing, we are in a kind of “tech gold rush” when it comes to Generative AI. Many organizations are rushing to implement the latest shiny AI tools without strategically analyzing the long-term consequences of this proliferation. Many of these tools require significant up-front investment due to their impact on data, security, and architecture.
Beyond coding, these AI tools can show up as part of the requirements, documentation, and customer communication processes.
This rapid adoption of AI tools that are too niche is creating a complex, fragmented architecture that will present maintenance challenges and increase the total cost of the tech stack.
Moreover, the reality is that many of these AI-driven tools are developed by start-ups, and as we know from past experience, some will not survive. This will leave companies with orphan applications that won’t be maintained.
Argument 2: AI Will Help Reduce Technical Debt
On the other side of the argument, we know that AI is a very powerful tool with the potential to remediate technical debt and even prevent it. But how could it be of help? Let’s take a look at some positive examples.
Reducing Duplicated Code or Duplicated Metadata
AI can scan through a codebase to identify repeated patterns and blocks of code or duplicate metadata, making it easier to consolidate them into reusable functions or modules.
Having a list of clearly identified duplicated code allows teams to start consolidating it.
AI for Refactoring
AI can streamline the refactoring process by suggesting more efficient, readable, and scalable versions of existing code.
AI For Code Review and Coding Standards
AI acts as an extra layer of quality control, reviewing code for errors, inconsistencies, and deviations from best practices.
AI can also be trained to understand and enforce coding standards across a team, ensuring consistency in how code is written and structured.
AI For Documentation
Well-documented applications enable teams to improve existing code bases with more confidence.
Additionally, Generative AI could assist by auto-populating missing description fields for objects, fields, and other components, making documentation easier and helping teams understand their purpose more clearly.
3 Ways To Approach Technical Debt In the Era of AI
To maximize the value of AI in development while maintaining control and sustainability, focus on these three key strategies:
- Prioritize long-term sustainability over short-term gains: Research, identify pain points, and be strategic when it comes to AI tooling.
- Keep a ‘human in the loop’: Ensure that the delivery teams have full control and understanding of AI generated code base.
- Use AI to remediate existing technical debt and to prevent it: Consider a tiered approach, starting by prioritizing the most pressing technical debt issues and empowering a dedicated team to remediate them.
Final Thoughts
In the short to mid-term, technical debt is likely to increase due to the rise of GenAI tools and the ease of generating code with LLM-powered code companions. However, if companies adhere to best practices, we may start to see technical debt decrease over the coming years.
That said, it’s not easy to get precise metrics on technical debt, so it might only be something we can partially assess a few years down the line. I believe it’s key for leaders and business stakeholders to be educated on the impact of technical debt and the business benefits of addressing it with a solid business case.
This responsibility of educating the business stakeholders falls on technical leaders, who need to step up as guardians of technical debt.
Comments: