How Spilled Juice is just like Technical Debt


This post presents an interesting and effective analogy to for those of us that struggle with handling technical debt: spilled juice.

Let's say that once day when you walk into your kitchen there is spilled orange juice on the floor - now you didn't spill that juice but you recognize the problem and clean it up. This is the natural instinct of most people, because if you don't clean up that juice when you see it the problem will only get worse. There are several ways in which the problem can only increase if you leave the juice where it is: you could walk through it and spread the mess through the rest of your home, you could risk having your dog lick up the spill and citrus is poisonous for dogs, or the juice could dry and attract insects that infest your home. These are only a few ways in which your problem can grow over time.

So how is this like technical debt?

If you walk into work one day open up a code file or start working on the database and run into some technical debt (either the code isn't clear, has some inconsistencies, or is lacking test coverage) you have a problem. However, you are more likely to do nothing about this problem than you are in the juice scenario laid out above. This maybe due to your belief that you don't have the authority to fix the problem, or that you don't think you have time to fix the problem because you need to get a new feature into production, or that you don't have the tools to pay back the debt. Ultimately, you can come up with and justify a plethora of excuses to not pay back technical debt in a way that you would not in the spilled juice scenario.

While you may think that technical debt is dissimilar enough to the spilled juice analogy to justify putting it on the back burner, it is just the same in that if left unattended the problem will only get worse. You will end up building new code on debt ridden code and adding onto your debt. You could spread poor quality data through different parts of the application or simply add new tests to new functionality while leaving existing functionality with poor test coverage. All this does is increase the cost of your technical debt in the long run.

So ask yourself: how can you possibly justify any excuse to continue a cycle like this?

What you have to do, is just like when you see spilled juice, is build a habit of cleaning up technical debt when you see it.

To read the full post visit here.

Filed in:
Get the Pulse Newsletter  Sign up for the latest Software Intelligence news Subscribe Now <>
Open source is part of almost every software capability we use today. At the  very least libraries, frameworks or databases that get used in mission critical  IT systems. In some cases entire systems being build on top of open source  foundations. Since we have been benchmarking IT software for years, we thought  we would set our sights on some of the most commonly used open source software  (OSS) projects. Software Intelligence Report <> Papers
In our 29-criteria evaluation of the static application security testing (SAST)  market, we identified the 10 most significant vendors — CAST, CA Veracode,  Checkmarx, IBM, Micro Focus, Parasoft, Rogue Wave Software, SiteLock,  SonarSource, and Synopsys — and researched, analyzed, and scored them. This  report shows how each measures up and helps security professionals make the  right choice. Forrester Wave: Static Application Security Testing, Q4 2017  Analyst Paper
Making sense of cloud transitions for financial and telecoms firms Cloud  migration 2.0: shifting priorities for application modernization in 2019  Research Report
Load more reviews
Thank you for the review! Your review must be approved first
New code

You've already submitted a review for this item