Is fear of technical debt holding you back?

I was thinking about the proper use of technical debt for Salesforce projects. Is it good? Is it bad? Have you failed if you have technical debt that needs to be addressed? As I did some reading to see if I was alone in my thinking, I was delighted to see that smarter people than me had thought about it a lot as well.

Let me start with my thoughts and work backward.

Salesforce projects can fail because of technical debt in three ways:

1. By incurring too much technical debt too quickly
2. By not properly returning to address technical debt
3. By not incurring enough technical debt, or incurring it quickly enough

Does the third conclusion surprise you? I was having a discussion regarding whether to migrate to a new instance, and the idea of getting rid of all the technical debt came up. It caused surprise when I asserted that zero technical debt is not the goal. I wouldn’t characterize everything they were dealing with as true technical debt, but even if I did, I believe the truth remains.

Zero technical debt is not the goal.

Technical debt is work that is delayed on purpose in order to learn or prove solutions more quickly. It is understood that the code being produced will require some refactoring – but we trade some capacity a little later to get to answers faster. This has the advantage of helping us fail fast – to reduce risk and get to the final product more quickly, even after accounting for the debt which has to be resolved.

Technical debt is produced by the decision to take a reasonable but suboptimal approach to a problem while the validity of the overall solution is being validated. If we are not taking reasonable risks and shortcuts, then we run the risk of being outpaced by someone with an inferior product and far superior momentum. If we incur technical debt too quickly or accrue too much before removing it, we run the risk of sacrificing momentum and suffering the hare’s fate while we stop to refactor. By not exercising the discipline of refactoring as we learn, we fail to evolve, and the shortcuts begin to weigh down the velocity at which we can evolve and produce new work.

If we are not taking reasonable risks and shortcuts, then we run the risk of being outpaced by someone with an inferior product and far superior momentum.

Technical debt that is consistently, intentionally created and removed through the process of learning the best solution is an indicator of a good agile process. This practice will allow you to best iterate to meet the needs of the users your systems support. I feel it is important to say that “a mess is a mess,” not technical debt. But I’ll talk about that another time.  For now, let’s agree that technical debt is never an excuse to be sloppy.

Software exists to make the lives of those who depend on it better. From customers to customer service agents, to sales, to executive leadership, good software helps people execute better, react more quickly, and see more clearly. If we aren’t taking enough risks to make some mistakes, incur some technical debt, and learn, we are limiting the success of the software to improve the lives of those it’s meant to help. So, avoid both recklessness and sterility in your code – by thoughtfully incurring and remediating technical debt so your software can allow your people to be the awesome folks that they are.

Technical debt should be both the tool and the byproduct of great thinking, and never the lack of it.