9 ms·

Stop Saying “Technical Debt”

63 points by HieronymusBosch 4y ago

arbitrage 4y ago
Technical Debt is anything your boss doesn't like this week.
danoni 4y ago
[flagged]
amelius 4y ago
Can we call it "the mess caused by unforeseen requirements"? Perhaps then managers will learn ...
cdchn 4y ago
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.
maerF0x0 4y ago
Ward cunningham references https://www.agilealliance.org/wp-content/uploads/2016/05/IntroductiontotheTechnicalDebtConcept-V-02.pdf https://www.agilealliance.org/wp-content/uploads/2016/05/Int... https://www.youtube.com/watch?v=pqeJFYwnkjE https://www.youtube.com/watch?v=pqeJFYwnkjE
IncRnd 4y ago
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] A 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. [1] https://en.wikipedia.org/wiki/Blind_men_and_an_elephant https://en.wikipedia.org/wiki/Blind_men_and_an_elephant
jakelazaroff 4y ago
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.
- joyfylbanana 4y ago
  The biggest difference is, that with financial debt you basically always have to pay it back in a way or another. With technical debt in startup context, it happens very often that you don't have to pay it back (failures). It is quite logical why startup founders prefer to have technical debt, as the venture is risky in any case it is the kind of liability that you only have to pay if you are successful.
  - jandrese 4y ago
    Also, sometimes the things that developers consider "technical debt" end up working just fine and don't cause that much trouble. There is always the urge to build something "the right way" where it's fully modular and extensible, but if you never need to extend something the additional layers of abstraction end up being more of a hindrance than a help. There is a certain level of efficiency in building things the cheap and easy way by default and only rewriting the parts where it was actually a problem.
    - Swizec 4y ago
stratigos 4y ago
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.
WaitWaitWha 4y ago
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)
- dogleash 4y ago
  > I always thought technical debt was a euphemism for speed over quality. For a first pass approximation it is. The post is a soup of manager-speak and blogger-speak. I might be too hungover to decipher it properly, but I'm pretty sure it's saying: go back and fix the places you scarified quality in the name of development speed, but only if fixing it will unlock more development speed. (And don't let those shifty fucks sneak in a refactor that doesn't bring any development speed RIO).
  - WaitWaitWha 4y ago
    I know it was not bourbon because that does no such thing. Rum? Tequila?
mbesto 4y ago
Let's just call it deferred maintenance and be done with it.
- shagie 4y ago
  I go with "baggage" for this reason. It's stuff that you need to bring along every time you move forward and the more you have the more you have to bring forward each time. Getting rid of it implies a check to see if you need it and some work to do that (while you can wholesale throw away things, sometimes you'll find that you've thrown away some important functionality).
guntherhermann 4y ago
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.
- infinitezest 4y ago
  You're not alone. This drives me nuts
- 000ooo000 4y ago
  I have decided as a rule that I just don't read the article. Based on past experience, they're so often garbage articles anyway.
harshaw 4y ago
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.
- pydry 4y ago
  I think the ranting is indirectly about the lack of any meaningful unit of account. Financial debt would be just as much of a mess if you couldn't count it. Somehow people think that if only we could explain what it was to people who don't get it the problem would be solved. Nope, just need to be able to measure it and stick a price on it (even if it's not much better than a guess) and let it be put it in a spreadsheet with all the other liabilities. The perpetual attempts at redefinition "so they get it", on the other hand, are all gonna get ignored.
  - Verdex 4y ago
    I think this is important. There's no real way to measure technical debt. The best we seem to have is cyclomatic complexity and lines of code. Not exactly what I would hope for. Alternatively we have 'best practices' (ie someone with an important title somewhere wrote a blog post about it) and 'code smells' (so ... the code makes your tummy feel bad when you look at it, yeah I'm sure that's objective). There are a few corners of the web where people have been trying things, but I don't know if I'm convinced. It is however better than nothing. https://www.sonarsource.com/docs/CognitiveComplexity.pdf https://www.sonarsource.com/docs/CognitiveComplexity.pdf https://www.progsbase.com/blog/flow-charts-of-programming-language-constructs/ https://www.progsbase.com/blog/flow-charts-of-programming-la... I don't think our industry is going to make any headway into a healthy way to deal with technical debt until we can talk objectively about the coding constructs that we're building. There's too many situations where people are conflating familiarity with objective quality. And even when you get past that the politics of having your coding philosophy win out means you can't trust enough people to honestly approach the issue. EDIT: Additionally, you have to worry about the external politics involved. If vendor A says the feature takes 3 months, but vendor B does the feature in 3 weeks, then it it's pretty clear who the customer is going to want to go with. That is until three days after launch when the module vendor B wrote keeps formatting end users' hard drives. OR MAYBE vendor A are just really bad at their jobs and their 3 month version would be the one formatting hard drives. Those who want software written do not have good metrics for how hard anything actually is.
mikece 4y ago
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.
robust-cactus 4y ago
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.
- marcosdumay 4y ago
  Why are any of your examples not tech debt? They all mean that there is some development work that must be done to get the software fit to the way you need it. Also this: > In all of these cases I feel like clean-up should just be constant and mostly opaque. This is true for almost all kinds of liability. People only insist on complete transparency for financial ones.
  - robust-cactus 4y ago
    That's my point - all these things get labeled as tech debt. Sounds like we're agreeing
tarkin2 4y ago
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.
NineStarPoint 4y ago
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.
- NineStarPoint 4y ago
  For this reason, I think maintenance load is a bad way to think of tech debt. Time spent not working on features represents design flaws that need to be fixed…but that’s separate from how I viewed tech debt to mean something. Maybe the article writer is correct that tech debt has become too overloaded a term. But we do need a term that describes not the easily measurable maintenance costs, but the harder to measure “extent to which the code’s state slows down programmers working on it”. That people will abuse this term to describe code they don’t like working on feels inevitable though, that’s just the human condition at work unfortunately.
pwinnski 4y ago
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.
- karmelapple 4y ago
  Agreed. On every PR we make, we have a template in the description to remind the author to document if we’ve taken out any technical debt. (And the author could list tech debt they’ve paid down, too) It’s a useful reminder that it’s there to use as one of the many tools in our toolbox.
1970-01-01 4y ago
>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/IntroductiontotheTechnicalDebtConcept-V-02.pdf 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"
zug_zug 4y ago
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)
csours 4y ago
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.
hermannj314 4y ago
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.
birdyrooster 4y ago
No
ilyt 4y ago
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"
resters 4y ago
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.
mostertoaster 4y ago
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.
deleted 4y ago
[deleted]
babbledabbler 4y ago
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.
photochemsyn 4y ago
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: https://github.com/sqlite/sqlite/blob/master/src/btree.c https://github.com/sqlite/sqlite/blob/master/src/btree.c
sublinear 4y ago
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.
flandish 4y ago
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.”
charles_f 4y ago
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
karmelapple 4y ago
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.

arbitrage 4y ago

Technical Debt is anything your boss doesn't like this week.

danoni 4y ago

[flagged]

amelius 4y ago

Can we call it "the mess caused by unforeseen requirements"? Perhaps then managers will learn ...

cdchn 4y ago

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.

maerF0x0 4y ago

Ward cunningham references https://www.agilealliance.org/wp-content/uploads/2016/05/IntroductiontotheTechnicalDebtConcept-V-02.pdf https://www.agilealliance.org/wp-content/uploads/2016/05/Int... https://www.youtube.com/watch?v=pqeJFYwnkjE https://www.youtube.com/watch?v=pqeJFYwnkjE

IncRnd 4y ago

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] A 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. [1] https://en.wikipedia.org/wiki/Blind_men_and_an_elephant https://en.wikipedia.org/wiki/Blind_men_and_an_elephant

jakelazaroff 4y ago

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.

joyfylbanana 4y ago
The biggest difference is, that with financial debt you basically always have to pay it back in a way or another. With technical debt in startup context, it happens very often that you don't have to pay it back (failures). It is quite logical why startup founders prefer to have technical debt, as the venture is risky in any case it is the kind of liability that you only have to pay if you are successful.
- jandrese 4y ago
  Also, sometimes the things that developers consider "technical debt" end up working just fine and don't cause that much trouble. There is always the urge to build something "the right way" where it's fully modular and extensible, but if you never need to extend something the additional layers of abstraction end up being more of a hindrance than a help. There is a certain level of efficiency in building things the cheap and easy way by default and only rewriting the parts where it was actually a problem.
  - Swizec 4y ago

stratigos 4y ago

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.

WaitWaitWha 4y ago

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)

dogleash 4y ago
> I always thought technical debt was a euphemism for speed over quality. For a first pass approximation it is. The post is a soup of manager-speak and blogger-speak. I might be too hungover to decipher it properly, but I'm pretty sure it's saying: go back and fix the places you scarified quality in the name of development speed, but only if fixing it will unlock more development speed. (And don't let those shifty fucks sneak in a refactor that doesn't bring any development speed RIO).
- WaitWaitWha 4y ago
  I know it was not bourbon because that does no such thing. Rum? Tequila?

mbesto 4y ago

Let's just call it deferred maintenance and be done with it.

shagie 4y ago
I go with "baggage" for this reason. It's stuff that you need to bring along every time you move forward and the more you have the more you have to bring forward each time. Getting rid of it implies a check to see if you need it and some work to do that (while you can wholesale throw away things, sometimes you'll find that you've thrown away some important functionality).

guntherhermann 4y ago

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.

infinitezest 4y ago
You're not alone. This drives me nuts
000ooo000 4y ago
I have decided as a rule that I just don't read the article. Based on past experience, they're so often garbage articles anyway.

harshaw 4y ago

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.

pydry 4y ago
I think the ranting is indirectly about the lack of any meaningful unit of account. Financial debt would be just as much of a mess if you couldn't count it. Somehow people think that if only we could explain what it was to people who don't get it the problem would be solved. Nope, just need to be able to measure it and stick a price on it (even if it's not much better than a guess) and let it be put it in a spreadsheet with all the other liabilities. The perpetual attempts at redefinition "so they get it", on the other hand, are all gonna get ignored.
- Verdex 4y ago
  I think this is important. There's no real way to measure technical debt. The best we seem to have is cyclomatic complexity and lines of code. Not exactly what I would hope for. Alternatively we have 'best practices' (ie someone with an important title somewhere wrote a blog post about it) and 'code smells' (so ... the code makes your tummy feel bad when you look at it, yeah I'm sure that's objective). There are a few corners of the web where people have been trying things, but I don't know if I'm convinced. It is however better than nothing. https://www.sonarsource.com/docs/CognitiveComplexity.pdf https://www.sonarsource.com/docs/CognitiveComplexity.pdf https://www.progsbase.com/blog/flow-charts-of-programming-language-constructs/ https://www.progsbase.com/blog/flow-charts-of-programming-la... I don't think our industry is going to make any headway into a healthy way to deal with technical debt until we can talk objectively about the coding constructs that we're building. There's too many situations where people are conflating familiarity with objective quality. And even when you get past that the politics of having your coding philosophy win out means you can't trust enough people to honestly approach the issue. EDIT: Additionally, you have to worry about the external politics involved. If vendor A says the feature takes 3 months, but vendor B does the feature in 3 weeks, then it it's pretty clear who the customer is going to want to go with. That is until three days after launch when the module vendor B wrote keeps formatting end users' hard drives. OR MAYBE vendor A are just really bad at their jobs and their 3 month version would be the one formatting hard drives. Those who want software written do not have good metrics for how hard anything actually is.

mikece 4y ago

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.

robust-cactus 4y ago

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.

marcosdumay 4y ago
Why are any of your examples not tech debt? They all mean that there is some development work that must be done to get the software fit to the way you need it. Also this: > In all of these cases I feel like clean-up should just be constant and mostly opaque. This is true for almost all kinds of liability. People only insist on complete transparency for financial ones.
- robust-cactus 4y ago
  That's my point - all these things get labeled as tech debt. Sounds like we're agreeing

tarkin2 4y ago

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.

NineStarPoint 4y ago

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.

NineStarPoint 4y ago
For this reason, I think maintenance load is a bad way to think of tech debt. Time spent not working on features represents design flaws that need to be fixed…but that’s separate from how I viewed tech debt to mean something. Maybe the article writer is correct that tech debt has become too overloaded a term. But we do need a term that describes not the easily measurable maintenance costs, but the harder to measure “extent to which the code’s state slows down programmers working on it”. That people will abuse this term to describe code they don’t like working on feels inevitable though, that’s just the human condition at work unfortunately.

pwinnski 4y ago

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.

karmelapple 4y ago
Agreed. On every PR we make, we have a template in the description to remind the author to document if we’ve taken out any technical debt. (And the author could list tech debt they’ve paid down, too) It’s a useful reminder that it’s there to use as one of the many tools in our toolbox.

1970-01-01 4y ago

>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/IntroductiontotheTechnicalDebtConcept-V-02.pdf 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"

zug_zug 4y ago

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)

csours 4y ago

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.

hermannj314 4y ago

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.

birdyrooster 4y ago

ilyt 4y ago

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"

resters 4y ago

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.

mostertoaster 4y ago

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.

deleted 4y ago

[deleted]

babbledabbler 4y ago

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.

photochemsyn 4y ago

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: https://github.com/sqlite/sqlite/blob/master/src/btree.c https://github.com/sqlite/sqlite/blob/master/src/btree.c

sublinear 4y ago

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.

flandish 4y ago

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.”

charles_f 4y ago

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

karmelapple 4y ago

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.