—
By Aaron Sylvan, 10x Senior Technologist
In my work as a senior consultant, I often work with companies struggling under the weight of technical debt. How do I approach these problems? As someone who brings an outside perspective, my insights can be transformative when teams feel stuck. Let’s dive in, explore the nuances of technical debt, and in the first part of this series, learn how to identify technical debt in your organization.
An Example of Technical Debt That Anyone Can Understand
Technical debt is akin to financial debt in a lot of ways; when a product isn’t built the right way, the “interest” accumulates until the organization pays the price. Typically, this starts as a series of shortcuts.
I’ll illustrate an example of what happens when an engineer violates a principle we call “DRY”, which means “Don’t Repeat Yourself.” If a concept appears in multiple places in code, ideally, it should be defined once and referenced elsewhere.
For instance, suppose we have a program to manage boxes of eggs. That program may have code in it like this, because eggs are sold by the dozen:
TOTAL_EGGS = NUMBER_OF_BOXES * 12
The correct way to program this would have taken a little more time:
EGG_BOX_SIZE = 12;
TOTAL_EGGS = NUMBER_OF_BOXES * EGG_BOX_SIZE
You can easily see why a programmer in a hurry will do it the quick way. It seems superfluous to define “egg box size” when we all know eggs come by the dozen. What I’m calling “the correct way” just looks like a lot more typing, right?
You’re right if it only happens in one place, like my example. But if we’re talking about a major egg-handling program, it probably appears in many places throughout the code. I know what you’re thinking: “But who cares how many times it appears, a dozen is always 12, so why waste time creating a symbol called EGG_BOX_SIZE when you can just say 12?”
Inserting that “magic number” throughout the code is a form of debt. It saved time at first, but the debt will need to be paid back when the Product Team declares the need to support egg boxes of sizes 6, 12, 18, and 144.
The Product Exec will say “I don’t see why this is a big deal; TBH we mentioned this on our roadmap last year anyway.” Meanwhile, the programmer will be thinking “Oh, no, I have to change the code in a ton of places.”
And I know what you are thinking: “Yeah, but find-and-replace to the rescue, right? What’s the big deal?”
FIND: 12
REPLACE: EGG_BOX_SIZE
Can it really be that easy? Let’s take it a step closer to the real world, and I’ll demonstrate how this simple debt can become truly toxic. Did I say we have an “egg-handling app”? Maybe that’s how it started, but actually our founder has extended our brand to be a “grocery handling app”.
We have a very large program, maybe 100,000 lines of code. Did I mention we also do beverages? Yes, of course we also handle 12oz cans of soda. So throughout our product, both of these statements occur in hundreds of places:
SODA_OUNCES = NUMBER_OF_CANS * 12
TOTAL_EGGS = NUMBER_OF_BOXES * 12
Our overwhelmed programmer, under pressure from Product, takes a shortcut and uses “Find and Replace All”. Our dev finds all the 12’s and changes them for the symbol “EGG_BOX_SIZE”. Now our code has these lines hidden throughout:
✅ TOTAL_EGGS = NUMBER_OF_BOXES * EGG_BOX_SIZE
❌ SODA_OUNCES = NUMBER_OF_CANS * EGG_BOX_SIZE
Uh-oh, the programmer tried to add a feature to the EGG code, and accidentally broke the SODA code.
And the coup-de-grâce: If this company also has the technical debt of poor automated testing, then it’s possible the apparently-unrelated soda bugs might not be noticed for weeks or months. At that point, it’s too late for a simple “undo”, or reverting the code to a previous version, because subsequent work has been invested throughout the codebase. This is the meaning of technical debt.
The product is hobbled, and cannot be repaired without someone making painstaking repairs. The work would have been much faster and cheaper if it had simply been done correctly the first time, which is why it’s like accruing compound interest on a loan.
There’s nothing wrong with the programmer putting in a “12” the first time the issue arose. It’s faster, like using a credit card to buy a coffee. But as the program starts to grow, the programmer needs to go back and clean up the shortcut — just like we pay down our consumer debt to avoid compound interest.
In the next part of this series, I’ll explain why for some projects, it could actually make sense to accumulate technical debt in a controlled manner, and how to identify signs that the technical debt in your company or organization may become overwhelming.