I’ve been reflecting on the proper use of technical debt in Salesforce projects. Is it beneficial? Is it detrimental? Does having technical debt that needs addressing indicate failure? While doing some research to see if I was alone in my thinking, I was pleased to find that many smarter minds had already explored this topic.
Let me start with my thoughts and work backward.
Salesforce projects can fail due to technical debt in three ways:
- Accumulating too much technical debt too quickly
- Failing to return and address the technical debt
- Not accumulating enough technical debt, or not doing so quickly enough
The third point may surprise you. I was in a discussion about whether to migrate to a new instance, and the idea of eliminating all technical debt was raised. It was surprising when I suggested that zero technical debt is not the goal. While I wouldn’t categorize everything they were dealing with as true technical debt, even if I did, I believe the point still holds.
Zero technical debt is not the goal.
Technical debt refers to work that is intentionally postponed to help us learn or prove solutions more quickly. It’s understood that the code will need refactoring, but we accept the trade-off of taking a little extra time later in exchange for faster progress in the present. This allows us to fail quickly, reduce risk, and move toward the final product faster, even considering the debt that needs resolving.
Technical debt arises from the decision to take a reasonable yet suboptimal approach while validating the overall solution. If we avoid reasonable risks and shortcuts, we may be overtaken by someone with an inferior product but far superior momentum. If we incur technical debt too quickly or allow it to accumulate without addressing it, we risk losing momentum and suffering the fate of the hare, stopping to refactor when we should keep moving. By not maintaining the discipline of refactoring as we learn, we fail to evolve, and the shortcuts accumulate, eventually hindering our ability to adapt and produce.
If we aren’t taking reasonable risks and shortcuts, we may be outpaced by someone with an inferior product and far superior momentum.
Consistently and intentionally creating and eliminating technical debt through the process of discovering the best solution is a sign of a good agile process. This allows you to iterate effectively and meet the needs of the users your systems are built to support. It’s important to note that “a mess is a mess,” not technical debt, but I’ll save that topic for another time. For now, let’s agree that technical debt should never be used as an excuse for poor work.
Software exists to improve the lives of those who rely on it. From customers to customer service agents, to sales, to executive leadership, good software enhances performance, improves response times, and provides clearer insights. If we don’t take enough risks, make some mistakes, incur technical debt, and learn from it, we’re limiting the software’s potential to improve the lives of those it’s meant to serve. So, avoid both recklessness and sterility in your code—incur and address technical debt thoughtfully, so your software empowers your team to be their best.
Technical debt should be both the tool and the byproduct of great thinking, not a sign of a lack of it.
