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. ...
For further actions, you may consider blocking this person and/or reporting abuse
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.