Technical debt is a lot like any other type of debt, except instead of accruing owed assets or money, you’re accruing the need for technical rework – which, in turn, does carry a financial cost.
Essentially, it’s a tension between the short-term payoff of moving quickly and meeting project deadlines versus a long-term investment in minimising rework.
Of course, that doesn’t mean short-term payoffs are inherently bad. In fact, the COVID-19 pandemic has taught many businesses that adapting quickly is not only beneficial, it’s sometimes urgently necessary. As a result, some degree of technical debt can be more or less unavoidable.
However, protecting your Salesforce instance and investment requires a careful cost-benefit analysis, balancing short-term and long-term impacts. After all, if you take on technical debt to accelerate a project now, but are making it harder to implement responsive changes to Salesforce in the near future, you could be undermining your own cause.
In some cases, that balance might require frontloading the work in the beginning and avoiding debt altogether, or allocating resources to tackle existing technical debt before it can become unmanageable. Either way, weighing these factors is easier if you consider the type of technical debt you might be facing.
What are the different types of technical debt?
In Salesforce, technical debt often involves excessive customisation, inefficient process approvals, redundancies, ‘spaghetti code’ and half-built clutter.
This can be the product of all kinds of technical debt, including:
- Code debt
- Design debt
- People or skill debt
- Testing debt
- Process debt
If the technical debt becomes significant, it can mean that, say, every change breaks something unexpected, requiring even more short-term fixes to move forward and creating a chilling effect for further change. That’s why, over time, prioritising a short-term payoff can actually impede speed and agility.
But this debt is often the result of different paths of reasoning. We can then differentiate types of technical debt by one main factor: intent.
Deliberate technical debt
As discussed, shortcuts are sometimes the right decision within the context of your business or project. Deliberate technical debt happens when an organisation makes this call, though the call may or may not turn out to be correct at a later date.
Before making this decision, it’s important to ask questions like: are we sure we understand the rework this will necessitate in the future? Will it accrue ‘interest’ in that future functionality or projects will depend on this technical debt? How many other goals or transformations might this shortcut impact?
Accidental technical debt
When new functionality supersedes features from prior releases, certain designs or fixes can become outdated. This is why a thoughtful roadmap is important – your business might decide the benefits outweigh the risks, but you’ll want to ensure you’re having that conversation now rather than being surprised with the costs of technical debt later on.
Bit rot technical debt
While this type of technical debt might be intentional or unintentional, it’s common enough to highlight here. This occurs when a functionality gets regularly extended through patchwork solutions, rather than simply being rebuilt.
It can be simpler for younger organisations to avoid this type of technical debt by focusing on greenfield implementations wherever possible. But that’s not always realistic for larger or more complex businesses, which is why it’s beneficial to look at how you can clean up technical debt.
How can you manage technical debt?
Since some technical debt is the reality for most organisations, managing technical debt is less about adopting a zero-tolerance approach and more about managing it in a deliberate, careful way.
The first and most crucial step is ensuring you’re aware of design choices and that your technical debt is intentional. That requires a proper audit and roadmap. But, once you’re aware of the debt you’re accruing, there are a few ways to keep it from spiralling and creating unmanageable problems in the future:
- Documentation. Formally track decisions and their rationale, while adding known debt to a backlog. This works for accidental debt, too, since you can start logging it as soon as the debt becomes known.
- Clarifying cost and value. Along with the other types of documentation, you’ll want to include estimates for how much it would cost to eliminate the debt. Additionally, documenting the anticipated value of resolving the debt can make future decisions easier, too.
- Assigning ownership. If no one owns the technical debt, it’s unlikely anyone will own its resolution – at least, not until it’s too late and already negatively impacting the business. Assigning ownership and giving backlog clearance the same weight as future enhancements will help preempt serious issues before they occur.
Once it’s time to address the rework necessitated by technical debt, things can get even trickier. Projects that promise new transformation are inherently sexier and tend to garner more momentum than clearing backlogs. Plus, teams still need to clear their BAU work, making the rework difficult to juggle.
That’s where Simplus Managed Services can be helpful. Functioning like an extension of your team, we provide a dedicated team of specialists who can help you clear backlogs, find new efficiencies and keep your Salesforce instance in tip-top shape.
