3 ms·

- https://docs.sonarqube.org/plugins/servlet/mobile?contentId=11636640#content/view/11636640 https://docs.sonarqube.org/plugins/servlet/mobile?contentId=... Th

by mlthoughts2018 8y ago

- https://docs.sonarqube.org/plugins/servlet/mobile?contentId=11636640#content/view/11636640 https://docs.sonarqube.org/plugins/servlet/mobile?contentId=... The worst tech debt is whatever is making the current quality leaks worse, generally whatever is being changed or added right now, usually in a hurry because someone shortsightedly thinks it’s business-critical to prioritize speed of delivery above quality standards. Maybe they are right, maybe they are wrong, but either way whatever they are asking you to break in order to get it done sooner, that is the worst thing going on. The more effort you spend focusing on making that process leak proof, the less future puddle there will be, leaving time to clean up the existing puddle. No matter what tech debt there is in older, not-currently-changing-due-to-project-needs code, it is like the puddle, maybe a large puddle, but it is not the leak.

shoo 8y ago
to attempt to reword what you're saying: the worst kind of tech debt is the kind that grows over time (perhaps as people interact with the system and continue to make changes to it)
- mlthoughts2018 8y ago
  I’m not sure if I would say that. Maybe we’re saying the same thing, but I would characterize it more by saying the worst tech debt is whatever is allowing new tech debt in code today. I think it’s specifically that the worst tech debt is whatever tech debt you are adding at the moment, whatever is changing in the code right now. It’s the leak vs. puddle analogy. Stopping the leak allows you to stop letting new tech debt get in, regardless of whether existing tech debt is a growing puddle. For example, when thinking about what tech debt to fix, a mistake I think people make is to focus on a big “systemic” piece of old tech debt that seems to grow because it affects new things and forces you to code around it or something. But the project has self-evidently been living with that tech debt already. It can be managed. In the meantime if some relatively harmless seeming tech debt continues to creep in through code reviews, that’s a worse problem, even if it’s not “growing over time” in the manner of a long-lived wart in the system.
piinbinary 8y ago
The link requires a login to view

shoo 8y ago

to attempt to reword what you're saying: the worst kind of tech debt is the kind that grows over time (perhaps as people interact with the system and continue to make changes to it)

mlthoughts2018 8y ago
I’m not sure if I would say that. Maybe we’re saying the same thing, but I would characterize it more by saying the worst tech debt is whatever is allowing new tech debt in code today. I think it’s specifically that the worst tech debt is whatever tech debt you are adding at the moment, whatever is changing in the code right now. It’s the leak vs. puddle analogy. Stopping the leak allows you to stop letting new tech debt get in, regardless of whether existing tech debt is a growing puddle. For example, when thinking about what tech debt to fix, a mistake I think people make is to focus on a big “systemic” piece of old tech debt that seems to grow because it affects new things and forces you to code around it or something. But the project has self-evidently been living with that tech debt already. It can be managed. In the meantime if some relatively harmless seeming tech debt continues to creep in through code reviews, that’s a worse problem, even if it’s not “growing over time” in the manner of a long-lived wart in the system.

piinbinary 8y ago

The link requires a login to view