Death and Taxes (and Technical Debt)

As the title suggests, the accumulation of technical debt is as inevitable as death or taxes.

Taxes and debt pair well as a metaphor, but what about death? This got me thinking about a health metaphor as an alternate way of imagining and managing technical debt.

For now, I’ll call this alternate metaphor “Technical Health.” From this perspective, it's easier to imagine a code base’s technical anatomy, monitoring for health metrics, and interventions. Let's take a look:

Technical Anatomy

Obviously, every project is going to have variations in how its code base is structured. You could just be starting with a simple amoeba, or you might have a Cronenberg monster on your hands.

You and your team can identify some basic structure and agreed-upon nomenclature to articulate your growing dysfunction better.

Here are some basic parts past teams I’ve worked with identified our code base’s anatomy:

Skeleton: The file hierarchy. Every folder is a bone — which, unlike humans, seems to grow in number as it matures.

Skin: Front-end code, public folder stuff. Bruises easily, but can look pretty if properly cared for and is almost completely replaced every 27 days.

Internal organs: API, endpoints, and Library files. Take in delicious data, remove toxins, extract valuable nutrients, process it, and on the other end, shoot out… value for our users.

Brain: The application's main file (app.js, server.js, api.js, etc…). Delegates out tasks to organs, the center of activity, provides endless anxiety when interacting with the real world.

Eyes, Ears, Mouth, Nose: Middle-of-stack Java script (angular, react, etc…) that takes in information from users and sends it to the brain. Occasional burps or hiccups.

Muscles: Infrastructure. How heavy of a traffic load can be handled? Flexing when trying to handle users.

You may find that your project’s parts may fit these categories differently, or you may have additional categories. This is just a useful abstraction that may help more easily describe technical debt to others.

Health Monitoring/Maintenance

Eat You Vegetables

I ate a vegetable once. It was cool, but it turns out that I need to keep eating them. By vegetables, I mean things like writing automated tests, handling errors properly, maintaining data backups, etc… And yes, I eat my vegetables now.

Exercise and Injuries

Exercise equates to your CI process. Build times starting to take longer and longer? Drop some weight, maybe build some more muscle. Injuries equate to build failures or bugs.

Detecting Issues

Do you keep getting boils on your skin? Continually covering them up with makeup may be working, but it's obvious that there’s something wrong on the inside. Deeper technical issues won’t be quite as obvious, but thinking this way can help detect the disease, not just the symptoms.

Cleansing

In my mind, the coding equivalent of a two-week lemon water and potpourri diet is simply removing old code that is no longer used. This is where I take the health metaphor a bit further, however.

I purposefully write most of my code in such a way as to make it quickly disposable, so rather than edit existing code, I will write new code to replace it. This forces me to keep everything very modular, small, and functional.

Old code get cleared out like old dead cells from our bodies.

Interventions

Medication

I consider this to include process and standardization changes. Like medication, process and standardization changes tend to take time to see improvements.

For example, adding a more formal code review process to your team’s pipeline will not have immediate benefits and will take a few iterations to do effectively

After some time, you may notice a significant improvement in your team’s output due to better knowledge transfer, less buggy code, etc…

Surgery

This includes direct actions, like refactoring, to remedy smells/sickness in the code base.

However, instead of simply refactoring to pay down the technical debt, we can quickly identify what kind of surgery we are performing and the effects it may have:

Quack: I’m going to perform heart surgery on system “x”

Slightly more experienced quack: That will affect the circulatory system and brain — we should be careful to take care of those too.

Lead quack: I didn’t realize how much is involved with this. The patient will be out for 4–6 weeks now. Does he even need the operation?

Rather than just focusing on debt repayment, we might think a little more deeply about where and how we are dedicating our efforts.

Conclusion

Metaphors are powerful devices. Using them to explain a more complex concept is useful, but it can also tie to it some aspects of the metaphor itself.

The technical debt metaphor may have you expecting to pay it down like you would a normal loan.

The reality may behave much differently — you wouldn’t expect your credit card balance to fluctuate wildly when you make a payment on your student loan.

With the Technical Health metaphor, I assume that people understand that the human body has many cross-dependencies between systems.

Making a change to your brain may paralyze an arm, taking a new medication may have side effects, etc…. This more holistic approach better matches how software projects actually behave.

So consider challenging your metaphors and how they may be affecting your decisions. You may discover better ways to communicate concepts, leading to better business decisions and ultimately helping your team forward!

If you found this valuable or entertaining, please follow the blog, and I’ll continue to post more tech goodness. Thanks for reading!