When you are deep in the code trenches, you understand how important is a clean and tidy codebase to keep a high level of productivity and quality. But how do we make this clear to non-technical peers and stakeholders?

Many use the technical debt metaphor to illustrate the idea that shortcuts will come back to haunt you if you don’t come back and fix them. Just as you might borrow money (cut corners in your development process) to increase your speed in the beginning, at the cost of some interest (a messy codebase) that needs to be repaid (fixed) later on.

However, I’ve always found the term technical debt ineffective and ambiguous. With financial debt, the repercussions of non-payment are both serious and clear, therefore the incentives to pay it back are high. On the other hand, technical debt is often pushed back to backlog tickets that continuously get sidelined for newer, business-valuable features. By the time we label something as “technical debt”, the window of opportunity to address it has already closed.

I believe a more useful framework is to talk about the work that a software engineering team does is running a kitchen in a restaurant, because there are plenty of commonalities between delivering software and cooking at scale, and many lessons can be learned from how kitchen staff works. Both cooking and software development are fast-paced activities that require a tight balance between housekeeping, creativity, planning, good processes and a focus on customer satisfaction.

Here are some talking points that you could use in your teams to bring home the idea that maintenance is vital to develop software in a long-term, sustainable way.

• Tools and equipment: Any professional operation requires of good tools and equipment. Think of your CI pipeline as the heart of the kitchen, like an oven, and a capable IDE as the chef’s favorite knife. You can still prepare nice meals with a dull knife, but the process will be less enjoyable and you’ll be setting yourself up for failure.
• Clean as you go: In a kitchen, just like with software development, it’s natural for things to get a little chaotic - as long as you tidy up as soon as you complete each feature. If there’s a lack of good structure and tests, it’s near impossible to continue the development process smoothly. Your team gets overwhelmed, and stakeholders grow frustrated and disappointed. In the worst cases, a full rewrite is the only way to move forward.
• Stick to the process: Kitchens are fast-paced environments where everything has to happen at the right time as customers await for their meal. There is some kind of beauty in watching kitchen staff working together on assembling hundreds of dishes every night under time pressure. This cohesion steams from a well-defined workflow, designed to optimally distribute each task and limit dependencies and bottlenecks between the different phases of the cooking process.
• Embrace change: Even when you follow a recipe to the letter, there might be times you’re out of an ingredient and you need to find a creative solution to finish your dish. In both cooking and software, the only constant is change. Both top-tier kitchens and proficient software development teams are good at adapting to changing scenarios, and improvising and experimenting with available resources.
• Test, try and refine: Would a chef serve a dish without tasting it first? Similarly, always test your code before deployment. I don’t need to remind you of that, do I?
• Prioritize the end product: Whether it’s a feature or a dish, what matters is the customers enjoy the final product. Do not let your software get cold in the counter, serve it up while it’s fresh!

Next time you’re explaining the intricacies of your coding process, remember the kitchen analogy. It might just be the recipe for understanding you’ve been searching for.

PS. In a follow-up article, I’ll compare software engineering with animal husbandry. Stay tuned!