top of page
  • Anton Pirker

Non-Technical Founders and Tech Debt

At some point in my career I worked as the second engineer and forth person in a startup that was founded by two non-technical founders.


Over the course of a a couple of months we cranked out features day in and day out. We grew the team to seven people and because more people worked on our shitty code base we could watch the broken window theory do its thing with our code base. The code quality deteriorating rapidly. It became harder and harder to implement new features, so I scheduled a meeting with the founders to tell them that we need some time to clean up the code and can not ship new features for the next couple of weeks.


But how should I explain to non-technical people what technical debt is? They did not know anything about software engineering. But I knew that one of them likes to cook. So I came up with the following story:


"Assume that building a new feature is like preparing a meal. Our code base is the kitchen with all the tools in it. And the prepared meal is our tasty new feature. In the kitchen that is our code base if we want to to prepare a meal right now we first go to the cutting board to discover it has still some half rotten kitchen scraps sticking to it, same goes for our favorite kitchen knife. So we first need to clean the cutting board and the knife in the sink. But in our sink there is a mountain of used pots, pans, and dishes. We see dried-up sauce sticking in the pans and there is a strange smell around the sink. As we touch one of the pans at the top of the mountain those tiny flies whirl around. OK, so we best put all those dirty dishes in our dish washer. As we open the dish washer we see that someone (or something) has shit in the dish washer..."


The story exaggerated the situation a bit, but it managed to bring the point across: We, the engineers can only deliver good software if we have a good and clean working environment. And as chefs need to clean their kitchen every day, we software engineers should also spend some time each day to keep our code base clean.


(The other moral of the story is that you should always use language that the persons you are communicating with understand.)

Recent Posts

See All

How to Refactor and Not Break Things

I am one of the maintainers of the Sentry Python SDK. In the SDK, we completed a huge refactoring, and I want to write down how we pulled this off without breaking (almost) anything and how we managed

How I feel when doing a massive refactoring

In all the years I have been developing software professionally I had to deal with a lot of code. At the beginning of the project, the code is mostly good but there comes a time in the life of every s

From 0% to Cleanly Refactored Code 100% Tested Code

A few years ago at Craft Conference in Budapest, I attended a talk by Llewellyn Falco called "From 0% to Cleanly Refactored Code 100% Tested Code". In his talk, Falco shows how he refactors a small pi

Comments


bottom of page