An actual example of technical debt

Suppose you’re doing an experiment on the direction you need to take your system’s architecture. So you hire a team to do a proof-of-concept for what you might do.

At this point in time, you don’t yet know the direction you want to go, and you don’t know if the project you’re having this team do is the direction you want to go.

So they build their proof-of-concept, making changes to your production system along the way. I mean, they’ve following your development practices of peer review and automated deployments. It’s not like they’re logging into the production servers and just coding there. Oh, you can be sure that the members of that team haven’t done something like THAT since 2008.

The proof-of-concept concludes, and you determine that the overall concept they proved has merit, but that the specific example isn’t useful as is. But you’re left with the detritus of the experiment in your code base—database migrations, feature flags, etc.

A scene from Tenet explaining inverted objects.

This is technical debt, and I think your org would be better served by calling it “incomplete work.” Even thought it made perfect sense to do the experiment, they haven’t cleaned up after themselves.

Nothing about the code is hacky or kludgey. It was done to exacting standards, but having completed the experiment, your knowledge has changed. It’s simply that the code from this experiment is no longer needed given your new understanding.

You could have spent a very long time trying to divine if this direction would have been good for your company, but you chose to move forward given imperfect information because it seemed like the fastest way to get better information. This makes strategic sense, and provided that you clean up the detritus, you won’t incur significant long-term cost.

If you don’t clean it up though, you’ll continue paying the carrying cost of additional complexity. If you build other features on top of the experimental code, then you’re going to have a bad time. So, if you need to modify that section of the code, the first step is to go and remove the experimental code (provided you haven’t already).

Calling this state “incomplete” makes it sound like something that needs to be addressed to prevent building further upon something you know you don’t want anymore. Calling it “technical debt” makes it sound like a something we can smartly keep around for a while.


Like this message? I send out a short email each day to help software development leaders build organizations the deliver value. Join us!


Get the book!

Ready to learn how to build an autonomous, event-sourced microservices-based system? Practical Microservices is the hands-on guidance you've been looking for.

Roll up your sleeves and get ready to build Video Tutorials, the next-gen web-based learning platform. You'll build it as a collection of loosely-coupled autonomous services, developing a message store interface along the way.

When you're done, you'll be ready to contribute to microservices-based projects.

In ebook or in print.