This article is also available on my blog.
I'm often confronted to the challenge of explaining to a non-tech person what the "Technical Debt" is. Or maybe I have to explain the difference between Good code VS Bad code, or between a good codebase VS a bad codebase.
More importantly, I often need people to feel what it's like to work with or without Technical Debt. How can a tech person convey the feelings of a work environment full of Technical Debt to someone who never coded in their life?
The best metaphor I could find is the kitchen.
The Technical Debt explained for tech people:
The Technical Debt is what happens when you try to take shortcuts in the development or maintenance of your application :
- You developed a new feature but the code is hacky, slightly disgusting, and you won't factorize it and polish it? That's technical debt.
- You're not taking the time to test your application? This adds to your technical debt.
- No time to update to the last version of your framework? More technical debt.
TD can come from pure laziness, or from a lack of technical skill, but that's extremely rare. The overwhelming majority of cases is a lack of time.
The Technical Debt is Very Bad©
Every developer worth their salt knows it: while small amounts of TD are not a big issue, and can even be desirable in some cases (i.e. you have a deadline you can't miss) in the long run an out-of-control Technical Debt will be a terrible burden for your whole company:
- It drastically slows your development speed in the middle / long term.
- It works as a feedback loop: the more TD you currently have, the more you will generate.
- It will make your engineers hate the work. More on that later.
- It can, in the end, literally destroy your company.
What it's like to work with Technical Debt: the Kitchen Analogy.
Imagine that you're a professional cook. A very good one, actually: after years and years of hard studies, you developed skills that are sought-after in the best 3-stars restaurants.
You just got hired in a new, promising restaurant: "The Unicorn". The pay is good. The team is great. You're psyched up for your first day.
Then on your first morning, you enter the kitchen and this is what you see:
Your first thought, obviously, is "What a f**** mess. This needs to be cleaned immediately and urgently". But the manager tells you there is no time, customers are arriving right now, so you'd better start cooking this instant.
Do you think you'll have a good, enjoyable first day of work?
Now realize this is what you'll be dealing with, 5 days a week, 4 weeks a month, for many years of your precious life.
Working in a dirty kitchen is extremely depressing. It will make everything you do a terrible chore. Even the simplest plate will be hard to prepare. You're going to serve shit, sometimes literal shit, to your customers. There will be bugs crawling everywhere, and every time you squash one, two more will appear. You will lose more time removing squashed bug parts from the customer's plates than you would spend cleaning or, you know, actually cooking good food.
Now imagine instead that this is what you saw when you arrived:
Clean. Polished. Everything well organized, easy to access. Just beautiful.
Will it be the same work experience?
There's a reason for the popular saying: "Technical Debt is debt you repay with your soul".
Why do we allow Technical Debt to exist?
There's a lot of reasons for a TD to grow out of control. None of them are good.
Young start-up on takeoff
The only maybe-somehow-acceptable situation where a TD can grow significantly would be at the very early stages in a start-up creation. You need to conquer market shares fast, so you need to develop fast.
Here's where the issues starts to appear, though. Because TD generates more TD, the start-up which doesn't take care of its TD early will then carry it for years and years, until it turns into a black hole destroying your company efficiency and slurping your developers wellbeing.
Bad management
Non-tech managers, sadly, do not understand what the TD is, and as I mentioned earlier, it is extremely difficult to explain to them the extent of the issue.
They will only see what is actually produced by the dev team, i.e. which features are getting out. They don't realize most of the work that happens under the hood.
If they end up measuring your productivity in features (or worse, in amount of code produced) without any regard for the Technical Debt, then programmers are actually incentivized to sabotage the codebase.
Bill gates said "Measuring programming progress by lines of code is like measuring aircraft building progress by weight.". A great analogy, since heavy aircrafts are harder to fly & more fuel-consuming.
Never worked in the clean
Programming schools often don't spend enough time on the necessity of a clean codebase. They usually just ask you to code small or medium-sized projects with a given list of features.
Therefore, a junior developer just out of school won't realize the importance of a clean work environment.
Now, if the junior joins a team of professionals who uphold themselves to high standards, they will realize how much better cooking in a clean kitchen is.
But usually, they will join a company with subpar coding practices. This will reinforce in them the idea that this is what coding is. Coding is hard, and annoying, and there's shit everywhere, that's just how the work is, and nothing can be done about it.
It is normal for a kitchen to look disgusting. That's how kitchens are.
Conclusion
I often hear stories of junior developers, "realizing the work is not for them" and wanting to quit the industry.
They feel stressed, burned-out, everything seems just so damn complex all the damn time. They're exhausted. They don't think they can keep doing the same work for 40 more years.
Every time I ask them about their work conditions, it becomes clear they've been working in the dirtiest kitchen.
We are literally losing developers under the dirty dishes.
It needs to stop. The Technical Debt culture is one of the major reasons why our work culture suck.
And it really doesn't have to. Just clean your damn kitchen.
Top comments (24)
An interesting analogy, but there's a difference: every piece of code becomes a technical debt, given enough time. The more time you invest up front, the longer it will take. Even so, technical debt is not inherently bad, it's inevitable. We only call it bad because we got better at what we do, thus what we did before looks worse now and reminds us of our previously worse selves.
That being said, we should definitely strive to minimize our tech debt. But we should also not feel bad about it. Tech debt is a chance for us to be our better selves as developers.
Eh, not so different: cooking anything in the kitchen generates dirty stuff. And the whole kitchen will also get dusty and dirty by itself, it will need some regular cleaning regardless of if we're using it or not.
The cleaning is part of the professional cooking. You don't usually leave your code dirty on purpose. In most cases, it's just that now you have more knowledge, more time and more incentive to improve it. It still fulfills its purpose. It's neither bad nor dirty - merely a chance to improve. Otherwise, we'd be talking about bugs, not tech debt. Granted, those would fit a kitchen analogy.
There is also the concept of entropy. Underlying languages change providing more efficient solutions and business requirements change meaning large parts if the code are simply redundant.
TD is just like monetary debt. You borrowed from your future pot of time to take a short cut and now you must continually pay a small price each day that goes by without refactoring. Each time you put in a filter to remove the test customer ID from your report or cast that string to a date because it has the wrong data type. Not only do you have the cost (capital repayment) of the original error you now have the compound Interest of fixing every workaround.
Or you declare bankruptcy and rewrite but cut the same corners because you don't have enough capital (time) to do the job properly.
There is also the concept of entropy. Underlying languages change providing more efficient solutions and business requirements change meaning large parts if the code are simply redundant.
TD is just like monetary debt. You borrowed from your future pot of time to take a short cut and now you must continually pay a small price each day that goes by without refactoring. Each time you put in a filter to remove the test customer ID from your report or cast that string to a date because it has the wrong data type. Not only do you have the cost (capital repayment) of the original error you now have the compound Interest of fixing every workaround.
Or you declare bankruptcy and rewrite but cut the same corners because you don't have enough capital (time) to do the job properly
There is also the concept of entropy. Underlying languages change providing more efficient solutions and business requirements change meaning large parts if the code are simply redundant.
TD is just like monetary debt. You borrowed from your future pot of time to take a short cut and now you must continually pay a small price each day that goes by without refactoring. Each time you put in a filter to remove the test customer ID from your report or cast that string to a date because it has the wrong data type. Not only do you have the cost (capital repayment) of the original error you now have the compound Interest of fixing every workaround.
Or you declare bankruptcy and rewrite but cut the same corners because you don't have enough capital (time) to do the job properly
There is also the concept of entropy. Underlying languages change providing more efficient solutions and business requirements change meaning large parts if the code are simply redundant.
TD is just like monetary debt. You borrowed from your future pot of time to take a short cut and now you must continually pay a small price each day that goes by without refactoring. Each time you put in a filter to remove the test customer ID from your report or cast that string to a date because it has the wrong data type. Not only do you have the cost (capital repayment) of the original error you now have the compound Interest of fixing every workaround.
Or you declare bankruptcy and rewrite but cut the same corners because you don't have enough capital (time) to do the job properly
There is also the concept of entropy. Underlying languages change providing more efficient solutions and business requirements change meaning large parts if the code are simply redundant.
TD is just like monetary debt. You borrowed from your future pot of time to take a short cut and now you must continually pay a small price each day that goes by without refactoring. Each time you put in a filter to remove the test customer ID from your report or cast that string to a date because it has the wrong data type. Not only do you have the cost (capital repayment) of the original error you now have the compound Interest of fixing every workaround.
Or you declare bankruptcy and rewrite but cut the same corners because you don't have enough capital (time) to do the job properly
There is also the concept of entropy. Underlying languages change providing more efficient solutions and business requirements change meaning large parts if the code are simply redundant.
TD is just like monetary debt. You borrowed from your future pot of time to take a short cut and now you must continually pay a small price each day that goes by without refactoring. Each time you put in a filter to remove the test customer ID from your report or cast that string to a date because it has the wrong data type. Not only do you have the cost (capital repayment) of the original error you now have the compound Interest of fixing every workaround.
Or you declare bankruptcy and rewrite but cut the same corners because you don't have enough capital (time) to do the job properly
There is also the concept of entropy. Underlying languages change providing more efficient solutions and business requirements change meaning large parts if the code are simply redundant.
TD is just like monetary debt. You borrowed from your future pot of time to take a short cut and now you must continually pay a small price each day that goes by without refactoring. Each time you put in a filter to remove the test customer ID from your report or cast that string to a date because it has the wrong data type. Not only do you have the cost (capital repayment) of the original error you now have the compound Interest of fixing every workaround.
Or you declare bankruptcy and rewrite but cut the same corners because you don't have enough capital (time) to do the job properly
There is also the concept of entropy. Underlying languages change providing more efficient solutions and business requirements change meaning large parts if the code are simply redundant.
TD is just like monetary debt. You borrowed from your future pot of time to take a short cut and now you must continually pay a small price each day that goes by without refactoring. Each time you put in a filter to remove the test customer ID from your report or cast that string to a date because it has the wrong data type. Not only do you have the cost (capital repayment) of the original error you now have the compound Interest of fixing every workaround.
Or you declare bankruptcy and rewrite but cut the same corners because you don't have enough capital (time) to do the job properly
The concept of entropy does not apply here. The informational content inside the code does not change if untouched. Yes, languages may develop and provide more sophisticated semantics to solve issues, but that is merely the wording, not the working. But you cannot possibly solve TD that stems from these changes up front. Please stop it with the "borrowing" and "bad code" stuff. This is just a negative approach when you should be positive about the whole thing. Tech debt can even happen in clean code environments.
But it does not mean something bad had happend; quite the contrary: it means that things improved - the knowledge of the developers and/or their understanding of the issues that are solved by the code, the language they are using or even the use case that allows using an improved solution.
That's my sole point here. Stop it with the negativity around tech debt. We should probably even find a better term to make it sound more positive.
Thanks for the well-written article and the great analogy! 👏
I really like how you focus on the effects on developers from the psychological viewpoint. It is rarely talked about, but extremely important!
About selling the idea of cleaning technical debt to non-tech people: I have always tried to convince managers to prioritize it by equating technical debt with actual financial debt. As time goes by, the interest on the debt accumulates (bugs) and they are not able to spend (develop features) as much as they need. Until eventually they have to declare bankruptcy.
As you said, sometimes it is ok to carry debt. But it has to be clear what the interest rate is and what is the plan for repaying it.
Converting code debt to money or hours of work is legit the best way I’ve used to convince managers to prioritize debt. :)
Do you wanna spend 2 Hours now, or 50 in 6 months?
thanks for this interesting addition!
"Non-tech managers, sadly, do not understand what the TD is..."
That's been my experience as well. I've heard them call bugs TD. But bugs are not TD, in general. Some might be, when the TD bleeds through.
Bugs are customer facing issues, and make the customer unhappy. TD is developer facing issues, and make the developer unhappy.
Sometime TD is caused by external factors. Like "OpenGL is out, Metal is in", or "Win32 is yesteryear, now move to WinRT (followed by, oops, just kidding)," or "those APIs that we deprecated 15 years ago? They're gone now. What do you mean we didn't give you enough warning?" or "68000, no no, PowerPC, no no, Intel, no no, ARM".
These kinds of externally imposed TD are part of the table stakes to stay in the game. Fortunately, they are the kind of TD that non-tech managers can understand.
The internal TD is the dirty kitchen. And who is to blame? The product managers? The project managers? The program managers? The product owners? The engineering managers? No, no, no, no, and no. The blame on TD is squarely on the shoulders of the developers. (My shoulders.)
It'd be nice to place the blame on someone else, but at the end of the day the managers are not the one's who made the mess... made the TD... the developers made the TD.
And the developers are the ones who have to clean up the TD, or suffer the ongoing pain of having TD.
Insightful comment, but I have to disagree in the end.
In a perfect world, managers let developers take as much time as they need to do their job properly. In this perfect situation, then indeed TD is the developer's fault.
But that haven't been my experience of the industry, nor the one of most devs I've been talking to. At least in the ecosystem I know well (startups and smallish tech companies), there is tremendous pressure to "shit as many features as possible" fast and furiously (half of them will never even be used.)
I'm not sure if that was a typo for "ship", or intentional... either way, I concur. And the wording as is is funnier.
The push back on the tremendous pressure has to come from the developers. Carving out some time to address the TD has to be driven by the developers. Identifying the TD has to be driven by the developers. Prioritizing the work to address the TD has to be championed by the developers.
Management will blissfully de-prioritize TD work over feature work or bug fixing work. Every time. Developers are responsible to make sure TD gets addressed, at the right time, with an appropriate priority.
Most professional developers I've worked with are good about keeping the code base clean as they go — working clean — when they can. The "Kaizen 5S" of software development. Or the mise en place of software development, to extend the kitchen analogy.
(I admit, I am a Clean Code evangelist.)
By far one of the best articles on this topic
Kudos 👏👏
Just started reading Code Complete. Read Clean Code a few months back. Totally agree with you on technical debt. I'm working on a project where the developer took a s**t over the clean code principles and because of that, adding new features is almost impossible. LOL.
This is at best a language sensitive observation. Clearly there is technical debt with c, c++ and Java,/ c#, where the language is compiled and isolated from the debugging environment.
It is a collossul waste of time when each new verison comes out in 3-6 months where because of an npm upgrade with new functions it forces a rewrite of the code.
Rewriting code is the best way to maintain, upgrade and keep the code state of the art and usually better than before.
Technical debt metaphor is perfect for waterfall or legacy code.
Otherwise it is just as they say "polishing the turd"
There is also the concept of entropy. Underlying languages change providing more efficient solutions and business requirements change meaning large parts if the code are simply redundant.
TD is just like monetary debt. You borrowed from your future pot of time to take a short cut and now you must continually pay a small price each day that goes by without refactoring. Each time you put in a filter to remove the test customer ID from your report or cast that string to a date because it has the wrong data type. Not only do you have the cost (capital repayment) of the original error you now have the compound Interest of fixing every workaround.
Or you declare bankruptcy and rewrite but cut the same corners because you don't have enough capital (time) to do the job properly
Such a well written article! Great details
As always, comments are welcome.