I work for a software engineering consultancy firm. During deployments, we’re often required to describe technical concepts to people across all levels of the client’s business. This can be challenging because of the wide range of contexts and technical knowledge possessed by people in different roles.
Clear descriptions and analogies are helpful because they increase the chance that everyone is on the same page. When everyone is on the same page, it is much easier to align goals and determine priorities that everyone can understand or get behind.
Technical debt is especially important to understand in a start-up environment — in a start-up environment, the need to move quickly and focus on customer value is much more pressing. Additionally, in a start-up environment, it’s much more likely to have all levels of the business in one meeting.
Tech debt is famously difficult to describe. It’s named after an analogy to financial debt made by Ward Cunningham, but my experience is that the financial analogy is not universally easy to reason about, making it hard to prioritise technical debt vs customer value.
Instead, I’ve found a kitchen analogy more successful when communicating the importance of technical debt. Here’s the analogy:
Technical debt is like ignoring kitchen tasks
Imagine that you’re managing a restaurant kitchen. The restaurant hasn’t opened yet, but let’s say there are critics wanting to try the food before it opens. Once they have arrived and ordered, it’s important that you get their meals out as quickly as possible.
In the process of preparing their meals, there are a lot of tasks that are unrelated to putting their food on the table — things like doing the dishes and keeping the pantry organized. When the objective is to deliver these two meals as quickly as possible, your team could avoid the tasks that don’t directly contribute to the delivery of the meal.
For example, they could grab what they need from the pantry without marking down what they took, or they could leave ingredients out after using them. They could leave the pots and pans in the sink instead of washing them, or they could leave knives and chopping boards where they were last used, without clearing the surfaces.
These dishes and unorganised pantry are the technical debt of the kitchen.
Tech debt can be fine
Working with a laser focus on a single goal (such as the delivery of a couple of meals) isn’t inherently a bad or inappropriate way to work — sometimes that deadline needs to be hit. The reviewers are waiting on their food (or you need that feature ready to demo to investors tomorrow). When it’s possible to have some relaxed time to organise the pantry and do the dishes after the meals are delivered, this delivery-only attitude can be very effective.
But things don’t always go to plan
You don’t always get the downtime you hoped for. Sometimes the team has to double down. “We loved the food and want to take some back to the office — can we get 40 serves of the sticky date pudding?”. Perhaps an investor will commit if you can complete a specific feature from your roadmap by the end of the month. Or they want to add some friends as test users, so you need to scale an element of the system.
In the kitchen, tech debt becomes a problem when you need to deliver the next meals — suddenly your team has no idea where the pasta is, or there are no clean pots to use. If it’s really bad, it’s not even as quick as cleaning the pot immediately – perhaps the pot that needs to be used is at the bottom of the pile, and food residue is now caked on.
Drawing the kitchen analogy into software
In the kitchen analogy, our team needs to spending time scrubbing dishes, hunting for ingredients that weren’t put away properly, finding the right pots and pans, or rushing to the shops to restock. In the software world, we have different problems.
A software team may need to spend time working through hard-to-read code that was written a month ago. Or, to deal with the aftermath of quick-and-dirty feature implementation, the team may find themselves changing and refactoring the old implementation while building an unrelated or new feature.
Coming back to do things later incurs a cost, too. If a small feature might have taken 30 mins to write tests for while the developers still had context, it can take much longer when the developers need to reconstruct the context (or if the code under test needs to be refactored before it can be tested).
Talking about technical debt in this way gives the team a tangible way to weigh priorities, too. “Well, we can rush that feature, but we’ll be making more dishes”. Or, “I think the kitchen is too dirty for us to start that next epic — I’d like to spend an afternoon on cleanup first”. We had a moment of pride when a client categorised their tech debt under the heading “dirty dishes”
We’ve found this analogy useful because it takes only a few moments to explain, is easy to grasp, and is relatable for almost everyone. Hopefully, you find it as useful as we have.