The Spilled Juice Analogy for Technical Debt

Orange Juice Spill

Imagine this: You go home tonight, you walk into your kitchen, and you see that there is orange juice spilled on the floor.  You’re the only one home, you know that you didn’t spill the juice, but there it is on the floor anyway.  This is clearly a problem.  What do you do?

Odds are that you clean it up, because you’re an adult and that’s what adults do.  You don’t walk through the orange juice because that would track it through the rest of your home, making the problem worse.  You could leave the juice there on the floor in the hopes that someone else will come along and clean it up. But if that doesn’t happen you run the risk of your dog lapping it up, and then getting sick from it because citrus is poisonous to dogs.  The problem will have gotten worse. Or perhaps the juice will slowly dry up, attracting all sorts of bugs, once again the problem gets worse.  Additionally, you’ll be forced to constantly walk around the spilled juice thereby slowing you down.  But luckily you’re an adult so you take a few minutes to clean up the juice and thereby avoid these obvious problems.

Now imagine this: You go to work tomorrow, you open up a code file or begin working with a database, and you discover some technical debt.  Perhaps the code isn’t very clear, perhaps the data has inconsistencies, perhaps there isn’t sufficient tests in place, or perhaps there’s a myriad of other issues.  This is clearly a problem.  What do you do?

Odds are that you do nothing about it.  You’d like to do something about it, you yearn to do something about it, but you perceive yourself as not having the authority to do so.  Or perhaps you don’t have the time to fix the problem because you need to focus on getting that new feature out the door.  Or perhaps you don’t have the skills to fix the problem, or the tools to do so, or even recognize that the problem can be fixed (for example, many data quality problems exist because the vast majority of data professionals haven’t learned fundamental techniques such as database testing and database refactoring).  Or perhaps you don’t have the funding to fix the technical debt because the business doesn’t understand it and as a result chooses to fund new development over paying down technical debt.  Or perhaps you see the problem as being overwhelming, not realizing that you can chip away at it a little bit at a time.  Or perhaps you realize that you can safely ignore the problem and let the next person to run into it to worry about it, just like someone in the past has clearly done to you. The point is that you have a litany of excuses to choose from for why you can’t fix the technical debt, so unlike the orange juice spill you don’t clean up the mess.

Unfortunately, just like the orange juice spill, the technical debt problem will only get worse.  You’ll build new code on top of the poor quality code, adding to your overall technical debt.  You’ll propagate the poor quality data through yet another part of your application, adding to your overall technical debt.  You’ll add new tests (hopefully) for the new functionality you’re adding but won’t take the time to add tests in for the existing functionality, adding to the cost of that existing technical debt.  How can this possibly be a good thing for you, or for your organization?

The solution of course is that we need to become the equivalent of software adults, or as many people would say software craftspeople.  This is a choice.  It takes time and it takes investment in yourself.  Just as it took you years to build up the habit of cleaning up spilled juice when you see it (I’m going to go out on a limb and assume that when you were a child you had to be told to clean up the juice many times before you built up the automatic habit) it will also take time to build up the habit of automatically addressing technical debt when you discover it.  While you are on your learning path you’ll also need to convince your colleagues to do the same.  You’ll also need to work with your business stakeholders, the people who fund IT, to understand the implications of technical debt and help convince them to invest in paying it down.  As an organization you need to choose to dig your way out of the technical debt pit.


Have any Question or Comment?

5 comments on “The Spilled Juice Analogy for Technical Debt

I like this concept because the juice is clearly in the way. I’m no fan of technical debt, but I prefer the dog shit metaphor. You clean it up where you play, but that dried up pile behind the compost bin isn’t high on the radar.

In the code I’ve seen, we could spend the entire budget cleaning code unless we pragmatically pick and choose which code to clean.

Jim Hobday

Unfortunately, there are still “adults” that won’t clean up spilt orange juice at home or for that matter spilt drinks in a workplace kitchen (well it’s not their job, mummy) so they won’t even get the analogy.

But I like it. Thanks.

Ramu Iyer

Conway’s Law states that software (or the structure of an IT system) mimics and is isomorphic to the organizational-social structure around it. In layman’s terms, a poorly designed software system is a vivid indicator of the underlying pattern of team communication, coordination and cooperation in the software team. Oftentimes, strained social and organizational interactions get in the way of smooth software development and operation. This results in social liabilities during intergroup coordination and accumulates “social debt” within or across one or more communities in a (software) organization. Any suboptimal socio-technical decisions also impact the technical debt of a software system in tandem. Digging one’s “way out of the technical debt pit” also requires the proactive mitigation of social debt around a system.

D. A. Tamburi, et al. Social debt in software engineering: Insights from the industry. Journal of Internet Services & Applications, 2015.

Pankaj ahuja

Good analogy and its association with tech debt.
Couple of questions cropped up while go thr the article –

1) being adults – one should not be dropping orange juice intentionally!
2) Or the tools provided to person assigned the reaponsibility of pouring juice were not adequate enough to prevent spilling. Which in software world could be analogues to lack of planning, rushing things or working on a evolving architecture/design type of environment. The juice was not spilled intentionally by the adult – its the environmental issue.

3) why should business(IT sponsor) is expected to understand what technical debt it? “Intentional” juice spill by “mature adult” is not exceptable. “Un-intentional” spill rather than calling it tech debt – should it be called ” retrofactor” and part of evolving software/solution.

Do you agree?


Pankaj, responding to your points:
1. Yet juice still gets spilled unintentionally.
2. Sometimes that’s the issue, sometimes the people injecting technical debt don’t understand the implications of what they’re doing, often due to lack of skills, experience, or education. Arguably also an environmental issue too.
3. Because they’re the ones who are going to have to pay for it. More importantly, if they don’t understand the implications of technical debt and how it comes about they’re likely to get more if it the future. To your point #2, it’s often poor decisions on the part of business stakeholders that lead to the environmental challenges.


Leave a Reply

Your email address will not be published. Required fields are marked *