Everybody knows what “monetary” debt is. We’re all familiar with Credit Cards, Mortgages, Lines of credit, etc. However, there is another type of debt that you’re likely not aware of that is compounding every day and can cause more havoc for your organization than any of the traditional types of debt. It can grow with every feature or enhancement you put into your information systems and can get to the point where you have no choice but to spend loads of time, money, and resources dealing with it. This insidious form of debt is called Technical Debt.
Technical Debt has many different definitions based on where you look, but at its core, it is the implied cost of additional rework to a system due to the accumulation of changes made by taking the cheap/easy route versus taking a more long-term approach by adding features and capabilities to a system.
In the beginning, it seems harmless enough. A small change here or there doesn’t have any noticeable impact. However, over time, with change after change being made to the system, the impact of each of these changes ends up having a multiplying and eventually exponential impact on the complexity, difficulty, effort, and ultimately the cost of each incremental change that is needed to be made to the system.
Eventually, it can cause organizations to become paralyzed with their current systems, preventing them from even making what should be insignificant changes to the system risky and cost-prohibitive to make vs the benefit they provide.
A Story on Technical Debt
I see it all the time with new clients of ours. The specific reasons for it and the route they took to get there have their differences, but their stories are similar.
I’ll protect the identity of one specific client, but this is how it happened for them.
ACME Widgets is a small business that sells widgets online. They started off small and in the beginning, the Founder built out her e-commerce storefront with the help of a few freelance developers. The business was pre-revenue and so money was tight and warranted the need to be as scrappy as possible when building out their infrastructure. Over a short period of time, ACME began to get traction in the online widget market and needed to invest in some more scalable systems to drive its next phase of growth.
ACME purchased Salesforce.com and Accounting Seed (native Accounting on Salesforce) so that they had a powerful, flexible, and scalable platform that would allow them to create a system that was tailored to their specific business processes. The founder spent her nights and weekends learning Salesforce so that she could self-implement and save herself some cash. She did an admirable job for somebody with little to no technical background.
She started out small and got the basic system running, albeit in a very manual manner. Over time, however, she began to add small automations here and there to do things like sync orders from the e-commerce platform to Salesforce and then built on top of those automations to create automated invoices, payments, etc in their accounting system.
She wasn’t doing anything wrong, and her resourcefulness and innovation should actually be applauded, but after a while, her pride in what she had built turned into something else. As her company began to have more traction, transaction volumes increased. However, her basic automations were not specifically built to handle the level of volume that was being pushed through the system. Over the course of the next year or so, issue after issue began popping up. She did what she could to fix it, even hiring some low-cost freelancers she found on UpWork and consultancies that provided low-cost (i.e. offshore) resources. However, none of these solutions addressed the root cause and each “fix” was similar to the little boy putting his finger in the dyke. She’d fix one issue (or really the symptom), which would just cause other issues to pop up almost immediately somewhere else. This continued until she simply could not handle it on her own anymore.
By the time she reached out to us, it was BAD. After listening to her concerns and performing a system audit, we came back to her with the news. It was going to take hundreds of hours of our services to correct the issues and stabilize the system. It’s not that anything she had built up to this point was bad, but it simply lacked the intentionality and foresight to be architected for what its role would be as the company grew and volume and complexity increased.
It’s a tough situation that I understand very well. As a business owner, you want to invest “just enough” to reach that next plateau and build from there. You don’t want to over-invest in something if you aren’t sure the payback will be there. You want to first prove your idea before you seek to perfect it or optimize it. I completely agree with the previous statement. We call it “premature optimization” and we actively counsel our clients to not overinvest in non-essential features before you’ve proven the core hypothesis.
However, every additional feature or automation you put into your system comes with some level of technical debt, and the interest is due with every subsequent feature you add to the system. The key is minimizing this debt on a regular basis by re-factoring and taking a longer-term approach when architecting additions to the system.
Minimizing Technical Debt
An entire blog series could be written on how to minimize and routinely pay down technical debt. But for you small business owners or operators out there that are being scrappy and self-implementing as much as possible, here are some things to keep in mind to help out.
Citizen development for Proof of Concept, experts for Production
Consider using your own internal resources to build out POC’s to prove a piece of functionality on a short-term or experimental basis. If the functionality proves to provide the desired benefit, turn it over to professional Salesforce architects and developers to “future proof” it and ensure it will viable for a longer period of time.
Building for a “reasonable” future
There are two extremes, building for today’s needs without regard for the future, and building for a future that has a very low probability.
The gold lies somewhere in between. You need to build your solutions to give you enough runway of growth for the next several years but is built in a manner that extending it further is accomplished with a reasonable amount of effort.
Design Reviews
Get somebody with experience in the boat with you, even if you are an expert. Having a design review process where somebody besides the person building the feature reviews what has been designed, tests assumptions, and asks additional questions can greatly improve the quality of the resulting feature. You’d be amazed at what a few simple questions from somebody with a different perspective can do to improve how you both think about what is needed to be built.
Thorough Testing
Test for the assumed level of volume for current and realistic future scenarios.
If you think your business and thus your system volume will grow 10x over the next five years, go ahead and test your features with this amount of volume in mind and see how well it performs. How far out you decide to go is up to you based on how probable the level of growth/expansion is.
Refactoring
With each change, review how the requested change interacts with existing features. Often, you will come across an automation or piece of code that used to be fit for purpose but could be improved to extend its life in the current environment. While this may not have been the primary purpose of the current change, this is the type of “debt paydown” that will help you prevent much larger interest payments in the future.
Partner with firms offering expertise in software design/development
Even though many consulting firms are transactional/project-based, there are others (shameless plug) that offer subscription-based services that come out to a fraction of the cost of a single Admin/Developer.
These services, often called “Managed Services”, typically provide Project Managers, Developers, and Architects that can help you manage your overall system and co-curate a roadmap alongside your team that can keep technical debt at bay.
Conclusion
Technical Debt happens. It’s nearly impossible to prevent, but it can be managed and reduced. It needs to be explicitly discussed and addressed whenever deciding to make improvements to your system. If you implement some of the steps above and pay down some of the interest with each change you make, you will go a long way in preventing you from filing “technical bankruptcy” as ACME Widgets did in our story above.