Technology is a Kitchen

Software by itself is just that, software. The true purpose of technology is to automate or expand on existing human capabilities (e.g. enhanced mobility with cars or airplanes, communication via social networks, etc.) and extract more value from our current resources. So when we design technology, it’s important to think holistically about the real value produced. Because by itself, software is just useless ones and zeros. But when used effectively, it is a great value-producing tool.

Over many years working in technology, I’ve found that software often resembles a kitchen. Because when used effectively, they both produce incredible value for its customers but can introduce painful burdens if left unmaintained.

Why a Kitchen?

A kitchen is a place that requires some minimal investment into appliances like a stove, oven, pots, and utensils which converts raw materials into outputs much greater than the sum of their parts. A kitchen is pointless without a chef who knows how to use the appliances or how to prepare the ingredients in a way that makes a great meal.

Technology is the same.

Technology is an expression of ideas by a software engineer in the same way a chef creates unique and delicious meals. A great meal is delicious and fulfilling, whereas software can be exciting and helpful. The outputs of both the chef and engineer, when given the correct tools, produce enormous value. This has led to decades of new companies and business innovation.

But this all comes at a cost.

Everything that is produced takes some raw material (food, ideas, energy) and refines it into something of higher value. But in every manufacturing process, there are undesired outputs due to inefficiencies or the tools used. When a chef produces a meal, he requires ingredients to be cleaned and chopped, leaves stems or peels in the trash, or uses tools such as cutting boards and knives that become dirty after use. While cooking, the chef requires multiple pots, pans, plates, and utensils to prepare and serve the food.

All these expenses and undesirable outputs are necessary in order to prepare the meal. But that’s okay because the meal is a desired output.

In order to produce this value, the chef had to dirty multiple dishes, pans, knives, and more, leaving a visible pile of unusable tools in the sink. The chef created this “debt” to produce the desired value. And he can quickly pay it down by cleaning the dirty dishes in the sick and placing them in their proper locations. At this point, the kitchen is debt-free and can be used again in the future to produce more value.

Now compare this to technology.

A software engineer is the chef in question. In order to produce some business value, he has to dirty his tools, designing systems which are constrained by the limited amount of resources or time available. Shortcuts are taken to produce value before some predefined launch date. Comparing this to the kitchen, the launch date of the software product is the same as the expectation of a speedy meal. In both cases, the engineer and the chef need to go back and clean up the mess they made. Because if they don’t, issues start to appear.

Imagine if a chef didn’t clean their kitchen after preparing a meal. At best, the next time they cook, they clean up all the used pots and pans. But what if the meal doesn’t require all the dirty tools but just a single pan at the bottom of the sink filled with numerous other dishes. Now, in order to make that small meal, the chef needs to dig under all that stuff, pull out the single small item they need, while being careful not to break any of the delicate glasses in the sink.

If nothing breaks, great. If something does, well, it was avoidable. Now there is even a bigger mess to tend to.

The chef should have cleaned up after themselves when they had the energy and time to. Now, the small meal that should take only a few minutes requires careful pre-cleaning and preparation, adding significant time to make that small dish.

Technology is the same.

In order to deliver some large feature on time, engineers often have to make sacrifices in code cleanliness or architectural design. Maybe integration tests are not robust or configurations were hardcoded instead of dynamically generated. But these short-term workarounds are necessary to meet the imposed deadlines. Everything works perfectly with these hacks. The value produced is indistinguishable to the customer, who’s unconcerned about the shortcuts or the newly accrued debt. But to the engineer, they know things will start to break if new features are built upon the current design or scaled without going back and fixing the temporary workarounds. Incremental additions begin to take more time when they should be easy.

This is exactly like the chef and his dirty kitchen.

In this case, the engineer accrued technical debt and needs to pay it off before it becomes overwhelming and leads to things breaking and becoming unmaintainable. And imagine if a new engineer (or chef, to continue the analogy) comes in to try to clean things up without the same meticulous care and understanding of the tenured individuals. Something will definitely break and everyone starts pointing fingers and says, “Why was that put there?”, “Who did this?”, or, even worse, “I don’t know what happened but everything is broken and I don’t know how to fix it”.

Both technology and kitchens are important value producing tools when someone uses and maintains them correctly. However, both producing software and cooking a meal come at a cost.

In order to produce something of value, we also create waste. This is the debt required to finance our operations. However, what was once “good” and “necessary” debt can quickly become a burden if the interest and principal aren’t paid down. So in both cases, the chef and software engineer must clean up their mess to continue producing value in the future.

If they don’t, just like a dirty kitchen will hinder a chef’s ability to prepare a meal, technical debt left unchecked will always cause problems down the line.