8 ms·

A Taxonomy of Tech Debt (2018)

294 points by jakey_bakey 2y ago

uterusxdxs 2y ago
[dead]
ooterness 2y ago
Great article. The "contagion" factor is a useful concept that I hadn't seen before. Needs a [2018] tag.
abc-1 2y ago
Contagion is exactly why interfaces are one of the most important pieces of design and should be given significant thought. A beautiful interface with a suboptimal implementation can be easily cleaned up when time is allotted. The reverse is rarely true.
- deleted 2y ago
  [deleted]
- yodsanklai 2y ago
  Which is why I like languages that make interfaces very explicit, like OCaml or Ada. Most of the time, I don't want to see the implementation, just a properly documented interface. If people can't describe in simple terms the behavior of an interface, something is wrong.
- majormajor 2y ago
  I don't disagree but I think commonly you are missing one of two things that are necessary for a proper design: 1) time to design it 2) knowledge of exactly what it needs to do today and in a year Sometimes you're missing both. In which case I think you can prevent contagion from being too terrible by enforcing smaller modules and single responsibility in a compositional way. That doesn't require as much knowledge of the future or time, but just requires you to avoid high-surface-area interfaces that end up with lots of behavioral variants controlled via parameters in a nesting-doll style. Instead, move your config/parsing/behavioral decisions to the edges of your logic instead of letting them seep into all your underlying models too.
  - BobbyJo 2y ago
    > In which case I think you can prevent contagion from being too terrible by enforcing smaller modules and single responsibility in a compositional way. I would classify that as thoughtful interface design.
  - njtransit 2y ago
    > 1) time to design it Do good interfaces take more time than bad interfaces to write? Does adding more time really make interfaces better? I find that engineering quality (of which interface design is one facet) is largely a function of talent and experience. Time doesn't usually play a factor. Writing good code takes the same amount of time as writing good code, for the most part.
- appplication 2y ago
  Agree, but I’ve found designing robust, future proof interfaces to be one of the hardest problems in developing software. Even intentionally setting out to avoid tech debt at all costs, it’s just hard to do correctly. It requires more than technical bravado and architectural vision. It really does get into the realm of predicting the future.
  - abc-1 2y ago
    Look at how mathematicians build minimal yet complete definitions for inspiration. An algebraic system can be created with a set of operations such as multiplication and addition, and existing concepts can be mapped to this system, such as money, but the underlying algebraic system will never change. It is complete. Much of the system can be complete like this with forethought. The pieces that cannot can be factored out to the edges.
    - appplication 2y ago
      You’re not wrong in a theoretical sense, but building useful interfaces that your average dev can grok enough to build on top of requires higher level abstractions, approximations, and “reasonable defaults”. My experience is that only a small number of devs actually well understand the codebases they work in (and care enough to be thoughtful in interfacing with it). The majority of devs generally are happy to tack on their features and PRs to whatever random scaffolding they can, without regard or awareness for how their individual component fits into the larger system, or how it may be extended. And to be honest it’s not necessarily a bad thing, because they do need to get work done, and merging PRs shouldn’t be reserved for the enlightened. I guess I’m just pessimistic. The reason we don’t see perfect software is because we are not capable of producing it. At a certain point it all becomes spaghetti. If you work with software that isn’t spaghetti, it’s only because the people who care about it not becoming spaghetti haven’t left yet. This is good, but eventually they will leave, standards will decline, and you will become one with the pasta.
      - abc-1 2y ago
        Keep fighting the good fight. It’s more satisfying, even if entropy inevitably wins ;)
- InDubioProRubio 2y ago
  But contagion deforms interfaces. Its that moment in discussions, were everyone goes away from how it ought to be, to how we must implement it, due to the previously existing modules, you learn about that..
- TexanFeller 2y ago
  One must understand what a good underlying implementation looks like to expose a good interface, it's easy to implicitly bake stupid implementations into an interface that cannot be fixed by just changing the implementation. The example that comes to mind is sorting and paging behavior. Junior devs, and many seniors that should know better by now, OFTEN start with requests that use some variant of limit/offset parameters for paging which leads to terrible performance issues and anomalous behavior. How paging works efficiently and what sorting options can be supported with good performance is inherently coupled to the shape of your data and your choice of datastore. People that haven't been through this exercise at a lower layer have little chance of shaping the higher level interface appropriately unless they put work into the implementation up front.
  - immibis 2y ago
    Another example is synchronous vs asynchronous I/O.
- dogleash 2y ago
  > A beautiful interface with a suboptimal implementation can be easily cleaned up when time is allotted. That won't happen. Why toy around with your ticket database like that? Just close it to WONTFIX.
- taeric 2y ago
  History seems somewhat full of counterexamples, though? QWERTY is rather famous for not being an optimal physical interface. Steering wheels would probably be up there? In computers, you have x86 being the poster child of ostensibly suboptimal interfaces.
  - TremendousJudge 2y ago
    QWERTY proves GPs point, it's a suboptimal interface and basically impossible to get rid of now, even though we've moved the underlying implementation from typewriters to computer keyboards to touchscreens
    - taeric 2y ago
      Ah, if the point is just that you can't get rid of bad interfaces, I suppose that works. I was taking it more as a systemic problem caused by bad interfaces. Which is to say, I'd be hesitant to cede that this has caused any actual problems. Would be like complaining that AC is being superseded by DC and how this is proof of an early choice locking us into a bad choice. But it ignores all of the progress made in the interim. And the odd reality that enough effort can migrate anything. It just takes a lot of effort. And we are often quite willing to throw effort at things.
    - shiroiushi 2y ago
      Actually, I wonder if QWERTY is actually better for touchscreens than alternative layouts. In a better layout like Dvorak, the most commonly-used keys are grouped close together, mostly on the home row. This is great for typing because you don't have to move your hands and fingers as much and can reduce wrist strain. But QWERTY does the opposite, moving all the most-used keys to the non-home rows so you have to constantly move between the top and bottom rows. On a computer keyboard, this gives you RSI, but on a small touchscreen, this means the "keys" you're tapping on are generally farther from each other, so perhaps it makes it easier since you rarely tap on two keys that are adjacent.
      - taeric 2y ago
APublicMan 2y ago
My experience at big corporate is that (edit: unmanageable) tech debt is caused by undisciplined and unorganized scrum team. When you have a proper backlog of tickets, including tech debt tickets, the team will eventually fix the tech debt when there are not enough feature tickets to exhaust capacity.
- deknos 2y ago
  if tech debt would depend on some kind of methodology it would not pop up with XP/Kanban/waterfall. techdebt can even pop up in unorganized slowmo opensource software.
- loloquwowndueo 2y ago
  “Not enough feature tickets to exhaust capacity” - I don’t think I’ve ever seen this happen :) PMs and sales always manage to book all available capacity.
  - hinkley 2y ago
    I’ve done it once or twice. One particular time there was a lot of hand wringing about how there was nothing to work on. I about saw red. Tech debt and bugs. That’s what you work on. That incident really changed my perspective on people who talk about how tech debt is bad. Some of them will roll up their sleeves, but some just want to look high minded without putting in the effort.
- bbojan 2y ago
  > the team will eventually fix the tech debt when there are not enough feature tickets to exhaust capacity I have yet to visit this misterious universe you describe.
  - Swizec 2y ago
    > I have yet to visit this misterious universe you describe. The trick is to have 1 backlog. Tech debt and features live on the same list and it is up to the PM to prioritize. Engineering’s job is to argue cost. Good PMs will prioritize relevant tech debt or pull it in with feature work in the same area. They understand the tradeoff of go slow to go fast. They also understand when tech debt will never become relevant (because the feature is getting nixed, or hasn’t shown desired impact yet, or because the cost of interest is waaaay lower than the cost of paying it off in many cases). This only works when engineers have the discipline to look stinky awful code in the eye and say “not today” and stay within agreed timeboxes. You blow this estimate once or twice, get the PM in hot water with leadership, and you’ve lost the trust.
bbor 2y ago
Great article, from a technical perspective! I would say it’s more a “nomenclature” than a “taxonomy” because it’s neither exhaustive nor discrete (by design), but I might be mistaken there. I loved the physical examples for each especially, really thought provoking. As always, I have a philosophical nit to pick: the “three axes” introduced at the top are just “Return” and “Investment” from good ol’ RoI, with a subcategory added for a particular type of forward-looking/conditional Return. I’m guessing this decision has worked in practice and I don’t expect video game development practices to be absolutely scientifically sound, but some extra philosophical certainty never hurts!
dang 2y ago
Discussed at the time: A Taxonomy of Technical Debt - https://news.ycombinator.com/item?id=16810092 https://news.ycombinator.com/item?id=16810092 - April 2018 (113 comments) also this bit: A Taxonomy of Tech Debt (2018) - https://news.ycombinator.com/item?id=39782923 https://news.ycombinator.com/item?id=39782923 - March 2024 (1 comment)
leni536 2y ago
One important aspect is when you knowingly take on tech debt in return of some short-term benefit. Then this benefit becomes an other axis to weigh against.
- jamesfinlayson 2y ago
  I've heard this called "tactical debt" instead of "technical debt".
- salomonk_mur 2y ago
  Typically speed.
- grues-dinner 2y ago
  Just like real debt. Want a new building now to get work done, not in 15 years when you have the capital? Take out debt, baby! It's a tool, but a powerful and dangerous tool, and if you don't acknowledge you're using it and respect it, it'll hurt you. Or it'll hurt someone who accepts the grenade from you. Just like real debt.
  - et-al 2y ago
    And just like real debt, some tech debt has higher compounding effects than others. (Consider this fix cost and impact in the author's framework.)
    - grues-dinner 2y ago
      Yep. Missing a deadline because your debt kicked off a death spiral is Jimmy the Facestabber coming looking for his vig at 25% a week and breaking your knees, gently pushing back some nice to have features next release while you deal with the debt is "only booked a 4 star hotel because the mortgage was paid first that month".
resonious 2y ago
I gotta say, it's pretty amazing to me that this was written by an engineering manager. None of the EMs I've worked with would be capable of discussing our codebase at this level of technical detail. Even the ones that used to be engineers. Although to be fair, we don't have any EMs who were promoted from within. We have a bad habit of hiring managers from outside, as nobody internally really wants to stop doing engineering (myself included).
sanitycheck 2y ago
I'm not sure I'd even call "local debt" technical debt in ordinary circumstances - realistically there's always going to be mess somewhere, and encapsulating it away where it can't hurt anyone is normal. If it probably never needs to change unless requirements change (in which case any other implementation would also need to) it's fine. Perhaps if 24 minion instances constitute an actual problem (rather than just inelegance) their example for it is actually foundational debt related having a "minion" being the simplest primitive that would do the job when maybe something lighter could have existed.
- igornadj 2y ago
  The article goes into it a tiny bit, but the cost is the mental cost of when you do need to work on it, understanding it, and I would add keeping the tooling the same. Encouraging devs to have their changes include all modules, even those that are old and mature and don't need to be touched, is a good way of ensuring this doesn't build up to where it becomes a problem.
brightball 2y ago
I've used Contagion to describe tech debt ever since I first read this article. Does a great job.
cynicalpeace 2y ago
It seems to be missing the most common type of debt I've seen: Founder's debt. This was debt that was created by the founders to get the fast, good value tech out the door. Low hanging fruit that ends up being the foundation of the whole shebang. The founding documents of many countries fall into this category lol (but not USA! USA! USA!) Macgyver debt and foundational debt come closest, but neither quite outline this phenomenon.
jakjak123 2y ago
I have worked in 3 "startups" now, only coming in after they have started making enough revenue to pay normal ish salaries. The thing I have seen the most, is several of the founders have a blurry concept of what were ideas they had, what was actually built, and what of parts of what was implemented actually works.
ChrisMarshallNY 2y ago
> I define tech debt as code or data that future developers will pay a cost for. One of the best descriptions I’ve encountered. As in all debt, there’s a “threshold” that should be applied, at the time the debt is incurred, which balances the immediate needs, against the future costs. I feel that most people (not just developers) amplify the immediate, and deprecate the future costs. For myself, I have an almost pathological aversion to debt, of any kind. I will spend an extra day, factoring out stuff that might be useful, in the future. I seem to be right, about 50% of the time. That said, every time I do something like that, I reinforce habit, which accelerates my basic workflow.

294 points by jakey_bakey 2y ago

uterusxdxs 2y ago

[dead]

ooterness 2y ago

Great article. The "contagion" factor is a useful concept that I hadn't seen before. Needs a [2018] tag.

abc-1 2y ago

Contagion is exactly why interfaces are one of the most important pieces of design and should be given significant thought. A beautiful interface with a suboptimal implementation can be easily cleaned up when time is allotted. The reverse is rarely true.

deleted 2y ago
[deleted]
yodsanklai 2y ago
Which is why I like languages that make interfaces very explicit, like OCaml or Ada. Most of the time, I don't want to see the implementation, just a properly documented interface. If people can't describe in simple terms the behavior of an interface, something is wrong.
majormajor 2y ago
I don't disagree but I think commonly you are missing one of two things that are necessary for a proper design: 1) time to design it 2) knowledge of exactly what it needs to do today and in a year Sometimes you're missing both. In which case I think you can prevent contagion from being too terrible by enforcing smaller modules and single responsibility in a compositional way. That doesn't require as much knowledge of the future or time, but just requires you to avoid high-surface-area interfaces that end up with lots of behavioral variants controlled via parameters in a nesting-doll style. Instead, move your config/parsing/behavioral decisions to the edges of your logic instead of letting them seep into all your underlying models too.
- BobbyJo 2y ago
  > In which case I think you can prevent contagion from being too terrible by enforcing smaller modules and single responsibility in a compositional way. I would classify that as thoughtful interface design.
- njtransit 2y ago
  > 1) time to design it Do good interfaces take more time than bad interfaces to write? Does adding more time really make interfaces better? I find that engineering quality (of which interface design is one facet) is largely a function of talent and experience. Time doesn't usually play a factor. Writing good code takes the same amount of time as writing good code, for the most part.
appplication 2y ago
Agree, but I’ve found designing robust, future proof interfaces to be one of the hardest problems in developing software. Even intentionally setting out to avoid tech debt at all costs, it’s just hard to do correctly. It requires more than technical bravado and architectural vision. It really does get into the realm of predicting the future.
- abc-1 2y ago
  Look at how mathematicians build minimal yet complete definitions for inspiration. An algebraic system can be created with a set of operations such as multiplication and addition, and existing concepts can be mapped to this system, such as money, but the underlying algebraic system will never change. It is complete. Much of the system can be complete like this with forethought. The pieces that cannot can be factored out to the edges.
  - appplication 2y ago
    You’re not wrong in a theoretical sense, but building useful interfaces that your average dev can grok enough to build on top of requires higher level abstractions, approximations, and “reasonable defaults”. My experience is that only a small number of devs actually well understand the codebases they work in (and care enough to be thoughtful in interfacing with it). The majority of devs generally are happy to tack on their features and PRs to whatever random scaffolding they can, without regard or awareness for how their individual component fits into the larger system, or how it may be extended. And to be honest it’s not necessarily a bad thing, because they do need to get work done, and merging PRs shouldn’t be reserved for the enlightened. I guess I’m just pessimistic. The reason we don’t see perfect software is because we are not capable of producing it. At a certain point it all becomes spaghetti. If you work with software that isn’t spaghetti, it’s only because the people who care about it not becoming spaghetti haven’t left yet. This is good, but eventually they will leave, standards will decline, and you will become one with the pasta.
    - abc-1 2y ago
      Keep fighting the good fight. It’s more satisfying, even if entropy inevitably wins ;)
InDubioProRubio 2y ago
But contagion deforms interfaces. Its that moment in discussions, were everyone goes away from how it ought to be, to how we must implement it, due to the previously existing modules, you learn about that..
TexanFeller 2y ago
One must understand what a good underlying implementation looks like to expose a good interface, it's easy to implicitly bake stupid implementations into an interface that cannot be fixed by just changing the implementation. The example that comes to mind is sorting and paging behavior. Junior devs, and many seniors that should know better by now, OFTEN start with requests that use some variant of limit/offset parameters for paging which leads to terrible performance issues and anomalous behavior. How paging works efficiently and what sorting options can be supported with good performance is inherently coupled to the shape of your data and your choice of datastore. People that haven't been through this exercise at a lower layer have little chance of shaping the higher level interface appropriately unless they put work into the implementation up front.
- immibis 2y ago
  Another example is synchronous vs asynchronous I/O.
dogleash 2y ago
> A beautiful interface with a suboptimal implementation can be easily cleaned up when time is allotted. That won't happen. Why toy around with your ticket database like that? Just close it to WONTFIX.
taeric 2y ago
History seems somewhat full of counterexamples, though? QWERTY is rather famous for not being an optimal physical interface. Steering wheels would probably be up there? In computers, you have x86 being the poster child of ostensibly suboptimal interfaces.
- TremendousJudge 2y ago
  QWERTY proves GPs point, it's a suboptimal interface and basically impossible to get rid of now, even though we've moved the underlying implementation from typewriters to computer keyboards to touchscreens
  - taeric 2y ago
    Ah, if the point is just that you can't get rid of bad interfaces, I suppose that works. I was taking it more as a systemic problem caused by bad interfaces. Which is to say, I'd be hesitant to cede that this has caused any actual problems. Would be like complaining that AC is being superseded by DC and how this is proof of an early choice locking us into a bad choice. But it ignores all of the progress made in the interim. And the odd reality that enough effort can migrate anything. It just takes a lot of effort. And we are often quite willing to throw effort at things.
  - shiroiushi 2y ago
    Actually, I wonder if QWERTY is actually better for touchscreens than alternative layouts. In a better layout like Dvorak, the most commonly-used keys are grouped close together, mostly on the home row. This is great for typing because you don't have to move your hands and fingers as much and can reduce wrist strain. But QWERTY does the opposite, moving all the most-used keys to the non-home rows so you have to constantly move between the top and bottom rows. On a computer keyboard, this gives you RSI, but on a small touchscreen, this means the "keys" you're tapping on are generally farther from each other, so perhaps it makes it easier since you rarely tap on two keys that are adjacent.
    - taeric 2y ago

APublicMan 2y ago

My experience at big corporate is that (edit: unmanageable) tech debt is caused by undisciplined and unorganized scrum team. When you have a proper backlog of tickets, including tech debt tickets, the team will eventually fix the tech debt when there are not enough feature tickets to exhaust capacity.

deknos 2y ago
if tech debt would depend on some kind of methodology it would not pop up with XP/Kanban/waterfall. techdebt can even pop up in unorganized slowmo opensource software.
loloquwowndueo 2y ago
“Not enough feature tickets to exhaust capacity” - I don’t think I’ve ever seen this happen :) PMs and sales always manage to book all available capacity.
- hinkley 2y ago
  I’ve done it once or twice. One particular time there was a lot of hand wringing about how there was nothing to work on. I about saw red. Tech debt and bugs. That’s what you work on. That incident really changed my perspective on people who talk about how tech debt is bad. Some of them will roll up their sleeves, but some just want to look high minded without putting in the effort.
bbojan 2y ago
> the team will eventually fix the tech debt when there are not enough feature tickets to exhaust capacity I have yet to visit this misterious universe you describe.
- Swizec 2y ago
  > I have yet to visit this misterious universe you describe. The trick is to have 1 backlog. Tech debt and features live on the same list and it is up to the PM to prioritize. Engineering’s job is to argue cost. Good PMs will prioritize relevant tech debt or pull it in with feature work in the same area. They understand the tradeoff of go slow to go fast. They also understand when tech debt will never become relevant (because the feature is getting nixed, or hasn’t shown desired impact yet, or because the cost of interest is waaaay lower than the cost of paying it off in many cases). This only works when engineers have the discipline to look stinky awful code in the eye and say “not today” and stay within agreed timeboxes. You blow this estimate once or twice, get the PM in hot water with leadership, and you’ve lost the trust.

bbor 2y ago

Great article, from a technical perspective! I would say it’s more a “nomenclature” than a “taxonomy” because it’s neither exhaustive nor discrete (by design), but I might be mistaken there. I loved the physical examples for each especially, really thought provoking. As always, I have a philosophical nit to pick: the “three axes” introduced at the top are just “Return” and “Investment” from good ol’ RoI, with a subcategory added for a particular type of forward-looking/conditional Return. I’m guessing this decision has worked in practice and I don’t expect video game development practices to be absolutely scientifically sound, but some extra philosophical certainty never hurts!

dang 2y ago

Discussed at the time: A Taxonomy of Technical Debt - https://news.ycombinator.com/item?id=16810092 https://news.ycombinator.com/item?id=16810092 - April 2018 (113 comments) also this bit: A Taxonomy of Tech Debt (2018) - https://news.ycombinator.com/item?id=39782923 https://news.ycombinator.com/item?id=39782923 - March 2024 (1 comment)

leni536 2y ago

One important aspect is when you knowingly take on tech debt in return of some short-term benefit. Then this benefit becomes an other axis to weigh against.

jamesfinlayson 2y ago
I've heard this called "tactical debt" instead of "technical debt".
salomonk_mur 2y ago
Typically speed.
grues-dinner 2y ago
Just like real debt. Want a new building now to get work done, not in 15 years when you have the capital? Take out debt, baby! It's a tool, but a powerful and dangerous tool, and if you don't acknowledge you're using it and respect it, it'll hurt you. Or it'll hurt someone who accepts the grenade from you. Just like real debt.
- et-al 2y ago
  And just like real debt, some tech debt has higher compounding effects than others. (Consider this fix cost and impact in the author's framework.)
  - grues-dinner 2y ago
    Yep. Missing a deadline because your debt kicked off a death spiral is Jimmy the Facestabber coming looking for his vig at 25% a week and breaking your knees, gently pushing back some nice to have features next release while you deal with the debt is "only booked a 4 star hotel because the mortgage was paid first that month".

resonious 2y ago

I gotta say, it's pretty amazing to me that this was written by an engineering manager. None of the EMs I've worked with would be capable of discussing our codebase at this level of technical detail. Even the ones that used to be engineers. Although to be fair, we don't have any EMs who were promoted from within. We have a bad habit of hiring managers from outside, as nobody internally really wants to stop doing engineering (myself included).

sanitycheck 2y ago

I'm not sure I'd even call "local debt" technical debt in ordinary circumstances - realistically there's always going to be mess somewhere, and encapsulating it away where it can't hurt anyone is normal. If it probably never needs to change unless requirements change (in which case any other implementation would also need to) it's fine. Perhaps if 24 minion instances constitute an actual problem (rather than just inelegance) their example for it is actually foundational debt related having a "minion" being the simplest primitive that would do the job when maybe something lighter could have existed.

igornadj 2y ago
The article goes into it a tiny bit, but the cost is the mental cost of when you do need to work on it, understanding it, and I would add keeping the tooling the same. Encouraging devs to have their changes include all modules, even those that are old and mature and don't need to be touched, is a good way of ensuring this doesn't build up to where it becomes a problem.

brightball 2y ago

I've used Contagion to describe tech debt ever since I first read this article. Does a great job.

cynicalpeace 2y ago

It seems to be missing the most common type of debt I've seen: Founder's debt. This was debt that was created by the founders to get the fast, good value tech out the door. Low hanging fruit that ends up being the foundation of the whole shebang. The founding documents of many countries fall into this category lol (but not USA! USA! USA!) Macgyver debt and foundational debt come closest, but neither quite outline this phenomenon.

jakjak123 2y ago

I have worked in 3 "startups" now, only coming in after they have started making enough revenue to pay normal ish salaries. The thing I have seen the most, is several of the founders have a blurry concept of what were ideas they had, what was actually built, and what of parts of what was implemented actually works.

ChrisMarshallNY 2y ago

> I define tech debt as code or data that future developers will pay a cost for. One of the best descriptions I’ve encountered. As in all debt, there’s a “threshold” that should be applied, at the time the debt is incurred, which balances the immediate needs, against the future costs. I feel that most people (not just developers) amplify the immediate, and deprecate the future costs. For myself, I have an almost pathological aversion to debt, of any kind. I will spend an extra day, factoring out stuff that might be useful, in the future. I seem to be right, about 50% of the time. That said, every time I do something like that, I reinforce habit, which accelerates my basic workflow.