Stop Saying “Technical Debt”
The thing I like about “technical debt” that I haven’t seen any other terms capture is that, like financial debt, it is a tool. If you’re building a new feature, there’s often a choice between doing it “right” and doing it “quick”. And it’s not a choice with a correct answer. If it’s important to get the feature to market ASAP, it might make sense to build it quickly even though you’ll have to refactor it in the future!
Calling it “bad code” definitely misses the mark. IMO, it’s code that constrains you from doing things you want to do. Tech debt is almost always code that is tightly coupled to other code, which is why getting rid of it or working in codebases with a lot of it can be difficult.
The key is that (again, like financial debt) you need a plan to pay technical debt down. If there’s too much, you start drowning in it. And not all of it is a choice — sometimes things unexpectedly change and current code becomes a liability. But framing technical debt in architectural decisions as a tool and a choice has helped me understand better how to accomplish business objectives as an engineer.
I hear lots of folks rant about the term. However, if anyone asked me, I would say that you need to think closely about the word "Debt". Debt powers our economy - from bonds, to Mortgages, to student loans. Debt makes the world go around - it's a decision to pay more money later to get something done now. Tech debt is the same thing - once you just realize how amazing it is, e.g "you want tech debt because it makes something happen now" then this is a positive term, not a negative term.
So I say strongly - use the term. Don't let it be a synonym for bad engineering, but for choices.
All the examples in the blog post which mention tech debt actually do refer to the same sort of tech debt - something that people want to fix, change, implement, or add onto but have not, due to the march of time and business.
The differences that were mentioned to "types of tech debt" are similar to the parable of the blind men describing an elephant. [1]
[1] https://en.wikipedia.org/wiki/Blind_men_and_an_elephantA group of blind men heard that a strange animal, called an elephant, had been brought to the town, but none of them were aware of its shape and form. Out of curiosity, they said: "We must inspect and know it by touch, of which we are capable". So, they sought it out, and when they found it they groped about it. The first person, whose hand landed on the trunk, said, "This being is like a thick snake". For another one whose hand reached its ear, it seemed like a kind of fan. As for another person, whose hand was upon its leg, said, the elephant is a pillar like a tree-trunk. The blind man who placed his hand upon its side said the elephant, "is a wall". Another who felt its tail, described it as a rope. The last felt its tusk, stating the elephant is that which is hard, smooth and like a spear.
Technical debt is the best term for what it is, which is not "bad code." So while the author is technically correct when they say "Tech debt is more than just bad code," more than anything they seem to be saying "I don't understand tech debt."
The thing I like about the term is that unlike general "bad code," a company chooses to incur tech debt. The quintessential example is that a deadline looms, and doing a thing "right" would mean pushing the deadline, but taking a shortcut would mean hitting it. As an organization, there is a choice to be made, in much the same way people generally have a choice when incurring financial debt.
Of course, it's often not a simple choice, which is why both financial and technical debt are so common. But in both cases, the choice was made to gain benefits now in exchange for a higher cost later.
I can't be the only one who finds headlines that tell you what to do highly irritating.
How about you don't tell me what to do.
Convince me.
Show, don't tell.
I don't think "technical debt" in and of itself is a fatally flawed term. The issue is that any term that becomes widely used jargon loses the preciseness of its meaning. Unless you address the root problem of having terms lose their meaning, replacing "technical debt" with "maintenance load" will eventually fall into the same trap.
The same can be said for "stand ups" in which most people sit down, and for "agile" which usually doesn't involve the practices that produce agility on a team.
For me I like the term "technical debt" because it succinctly describes a complexity cost that accrues interest over time. It doesn't simply mean "bad code". You can work with that cost to prioritize more important work however eventually if you don't pay it down, it will catch up with you and you will be spending your time and money on paying off the interest rather than investing in your features.
Another term I like to use in tandem with "technical debt" is "technical investment". Technical investment is spending time and effort on things that will return a benefit over time, either reducing technical debt, or enabling more features.
I’ve always viewed tech debt at related to the extent to which the system’s code and design increases the difficulty of making desired changes to it. Decisions made yesterday increasing the difficulty of making desired changes today. The important point being that it isn’t only bad decisions in the past that can cause this tech debt. While the most recognized source of tech debt is rushing to meet deadlines and taking shortcuts, changing requirements or other parts of a product can cause tech debt to manifest where there wasn’t any before. Whenever previous architecture decisions were made that you now have to work around to get what you want done, that’s tech debt.
Which is I think why most people who have been in the industry for a while have a “good enough” feeling towards getting something done. Yes, you should put in an hour of work now to not have to put in ten hours of work tomorrow. But there’s no point in trying to make something perfect and debt-free for reasons beyond time efficiency. The march of time will cause a maintenance debt to accrue regardless, the difference between debt free and good enough disappears with time.
I like "maxing out the technical credit card." I think of technical debt as needful work that you just can't afford to do right now (usually in lieu of chasing features) so you "charge it" and then having to deal with a suboptimal situation you're then "paying interest" on that debt.
Folks need to be more concerned about code entropy than technical debt, often developers do not know the difference ;-)
The latter does allow progress, the former inhibits it.
Can we call it "the mess caused by unforeseen requirements"?
Perhaps then managers will learn ...
Including comprehensive comments, documentation and tests in a codebase takes time and effort.
Failing to do so creates code that is very difficult to maintain or for someone new to the codebase to understand.
However, time and effort may not be what the organization wants to pay for, and individuals may view their own incomprehensible code as something like job security, as they can't be replaced by someone else easily.
As an example of complicated code that's still well-documented, the open-source sqlite code is a good example, about 1/4 of the B-tree file is comments, every time a variable is defined there's a short note explaining what it's used for, every function has a comment header that's comprehensive, such that someone new to the codebase could construct a map of how it all works fairly quickly. It's a good model for how to avoid the problem:
I always thought technical debt was a euphemism for speed over quality. Slap the stuff together so it meets the milestone or deadline set by non-technical 'experts'. As in, the result lacks technical correctness & quality.
It is most often used in my experience not to hurt the feelings of Vice Presidents, while conveying the problem to those in the know. (/s)
Let's perform the 5-whys:
1. Tech Debt is a meaningless term
2A. Product/Management don't know the platform intimately, so sometimes developers lie and call things with no ROI tech-debt, or make up issues to explain missing deadlines
3AA. These engineers are intentionally dishonest have an antagonistic relationship with Product/Management and see them as task-masters.
4AA. Product often positions themselves as though they are "in charge of" engineers, and that they exclusively "own" the project.
5AA. Everybody likes to see themselves as the most important part of the company. Engineers think they built everything, product thinks they built everything, founders think they built everything, sales think they made all the money.
3AB. These engineers don't feel like they have an ownership stake in the product anymore, and take little pride in the product itself instead of pay/politics.
2B. Product/Management don't trust developers to accurately/honestly assess what is genuine time-saving tech-debt.
3BA. Some developers do lie (see 3AA)
No. The term is perfect and evokes exactly what it should evoke. That there is debt that will need to be paid sooner than later and that you should take it only if the "resources" (faster time to market) from that loan can be invested into "profits"
The age-old semantics discussion around how to handle refactorings.
> The thing is, those bugaboos rarely intersect with the code’s most pressing maintenance challenges. So when each engineer finishes their gang-of-four-fueled refactoring bender, the code is no easier to work in than it was before: it’s just different
This gets rehashed a lot in various forms that amount to "there is no right or wrong way of doing something as long as it works, it's all just personal preferences". While I agree there are many ways to do something, you sometimes (not even rarely) cross paths with hot piles of untested tightly coupled unscalable non-monitored non commented convenience-biased nonsensical garbage, that are obviously wrong.
> In all seriousness, this is a huge reason that spending three weeks paying down tech debt, carte blanche, often does little or nothing for the team’s velocity after those weeks have ended.
I think what's meant there is that refactoring for the sake of refactoring is pointless, which I couldn't agree more. What I don't agree with is that this is an argument for discarding the notion of technical debt. A strategy I found more efficient in that line is to tackle it while building features. Rather than playing alongside or worse, around the idiosyncrasies of something broken, fix it.
> we can track what specific elements of the system force feature development to take longer, measure them in terms of the amount of developer effort that they require
On paper, sounds like a great idea, but also like a lotbof bureaucracy added to a team who ironically probably already feels a lot of pressure because of said technical challenges. The other thing is that, it's rarely clear-cut, you rarely have entire tasks you wouldn't have done because of debt, rather it's just taking longer because of that debt. You're still left with estimating the refactored side
Overall what I take of the article is that the main point is not doing refactoring for its own sake. I don't actually gey the argument for why the term tech debt should not be used
The alternative to "tech debt" suggested in this article is "maintenance load" which immediately makes me think of naval aviation and why the iconic F-14 Tomcat was retired and replaced with by the somewhat more pedestrian F-18E/F Super Hornet: because it required less maintenance per flight hour -- a lot less maintenance. It doesn't matter to the nation you're trying to defend if your Tomcat is theoretically superior to another plane that could have done the job if the Tomcat is stuck in the maintenance hanger having it's hydraulics system fixed (again) at the hour an enemy decides to launch an attack.
Let's be honest. Most "technical debt" is caused by a lack of experience.
Product management asks for wildly unrelated, inconsistent, and redundant changes on a sloppy schedule with absolutely no regard for its effects to the integrity of the product. This happens when they are still useless middlemen who just pass messages and get used as punching bags.
Developers poorly reinvent existing solutions in ignorance and use every task as an opportunity to learn instead of just doing what's expected.
This isn't necessarily "bad", but it is where it comes from and reason to slow down a project if the code is expected to endure.
>Everyone who says "tech debt" assumes they know what we’re all talking about, but their individual pictures differ quite a bit.
Maybe someone should ask the person that coined the term what it supposed to mean? And we did. It's here:
https://www.agilealliance.org/wp-content/uploads/2016/05/Int...
Go ahead and say Technical Debt. If you want to check if someone is listening, use its French counterpart and say "Dette Technique"
Words are for communication, not being correct. It is good to have different words for the same concept if someone has some difficulty processing your words - be it understanding or emotional response.
Technical debt is fine for talking to other technical people, we've all learned what you mean. And of course you can break it down by urgency, block percentage, etc.
Maintenance Load sounds good for communicating to the people with the money, it explains why you're doing things they didn't ask you to do; and of course they can easily say no, just like we do in real life to infrastructure maintainers.
I find the most helpful way to think about it is to think that most tech debt is introduced by the product manager. A product is built according to spec, and then the spec changes, a new feature is added, a performance characteristic is changed, and now the engineer has tech debt he must resolve to satisfy the product manager’s spec.
This changes the conversation to where tech debt is good, but so is paying it down. Good engineers will better anticipate the possible future changes in requirements and design for them and will incur less “tech debt” to pay back when product adds a feature.
We define this term on our team, and talk about it every time a new teammate joins our team and participated in our once-per-sprint tech debt discussion.
Working from the same definition helps this.
And I don’t know why tech debt would even be coming up in discussions with sales or non-developer people unless you’ve got serious problems. And I’m that case, don’t focus on a phrase like “technical debt” - instead, use the phrase for what you’ve got: “serious problems” or whatever else the debt has manifested itself into.
undefined
One of my favorite quotes from a former colleague is "conversation creates its own weather patterns". For me, anytime if seen the words "tech debt" thrown around it starts to just weigh everyone down. People just start repeating the words over and over for all sorts of very tractable issues. The amount of time I've seen it falsely attributed/claimed is obscene.
1. Switched to microservices or a new language or anything more modern in 1 part of the codebase? Yea everyone now calls anything not that tech debt.
2. Have a performance problem and want to add more features? "Tech debt"
3. The code is just bad - "tech debt"
In all of these cases I feel like clean-up should just be constant and mostly opaque. The campfire rule is so great for these things - "just make the campground a little better than when you got there". It often does not take more time to just clean-up as you go. Then once you have your barings on a certain part of the codebase bigger changes will seem smaller and you can fix those up as well OR buy yourself that 2 weeks with a specific plan/ask. Eng cultures that worked this way seemed to work the best.
Sometimes technical debt is framed as an accident or a mistake, as if someone spent money on a credit card irresponsibly. And certainly sometimes that is the case.
But any kind of debt can enable leverage when it is done intentionally and with an understanding of the short term vs long term tradeoffs and risks.
The first drive on my computer is C and not A, my console is limited to 80 characters width, and everyone I know uses an Imperial measurement system.
Double down on your tech debt until it becomes a standard.
I prefer to phase it in two ways:
- before implementation, it’s a “milestone project management decided to ignore.”
- after implementation, it’s a “project management decision to implement in the next phase.”
This will incur a lot of "maintenance" later on.
I've always preferred that to technical debt.
Maintenance better implies time, employees and therefore money.
Obviously now when ChatGPT regenerates your entire codebase based on an ever growing detailed description then the idea of code maintenance and technical debt, rather than code readability, will need a rethink.
Let's just call it deferred maintenance and be done with it.
No
[flagged]
Technical Debt is anything your boss doesn't like this week.