4 ms·

I think this post has inspired me to improve the specificity of why something I see in the code is bad. It's not always possible, because if I'm discovering th

I think this post has inspired me to improve the specificity of why something I see in the code is bad. It's not always possible, because if I'm discovering the results of $SPECIFIC_REASON after the fact, often the context for why it's bad isn't obvious. When it's not obvious why it's bad, but is obvious that it should be changed: do I judgmentally call it a mess (that I didn't make)? Or should I declare it technical debt and endeavor to understand why the bad thing came to be?

louwrentius 6y ago
I would recommend to just call it for what it really is. Bad code. Why does it add anything to call it technical debt? You still have to dig deeper to really understand the problem anyway.
- ineedasername 6y ago
  You can call it bad code, but someone wrote that bad code. A few people worked on the same team when the bad code got through the cracks. Someone supervised that team, etc. And some of those people, or people they know, are still working around you. Technical debt may not be the appropriate term, but there are good reasons to be a little more tactful than saying "I have to fix someone's bad code that broke" so that you can continue to have good working relationships with the people around you.
- strken 6y ago
  Let's say I choose to hack together an interpretation layer for an API that another team controls instead of fixing their API's underlying issues. I'm deliberately choosing to write worse code for some business purpose (prototyping, legislative deadline, evaluating one API out of many, etc.). We assume that in the future other business purposes (stability, maintainability, other teams using the product, we decided on a direction) will necessitate more work to fix this hack. I need to explain to non-technical people that this will eventually need more work to be fixed. What metaphor should I use to explain taking on temporary business risk now to save time, then spending more time in total to fix it in the future?
- rjkennedy98 6y ago
  > I would recommend to just call it for what it really is. Bad code If you work on a team, that just isn’t going to fly. I can’t imagine the toxicity of an environment where someone constantly was calling out other people’s code as being “bad”.

louwrentius 6y ago

I would recommend to just call it for what it really is. Bad code. Why does it add anything to call it technical debt? You still have to dig deeper to really understand the problem anyway.

ineedasername 6y ago
You can call it bad code, but someone wrote that bad code. A few people worked on the same team when the bad code got through the cracks. Someone supervised that team, etc. And some of those people, or people they know, are still working around you. Technical debt may not be the appropriate term, but there are good reasons to be a little more tactful than saying "I have to fix someone's bad code that broke" so that you can continue to have good working relationships with the people around you.
strken 6y ago
Let's say I choose to hack together an interpretation layer for an API that another team controls instead of fixing their API's underlying issues. I'm deliberately choosing to write worse code for some business purpose (prototyping, legislative deadline, evaluating one API out of many, etc.). We assume that in the future other business purposes (stability, maintainability, other teams using the product, we decided on a direction) will necessitate more work to fix this hack. I need to explain to non-technical people that this will eventually need more work to be fixed. What metaphor should I use to explain taking on temporary business risk now to save time, then spending more time in total to fix it in the future?
rjkennedy98 6y ago
> I would recommend to just call it for what it really is. Bad code If you work on a team, that just isn’t going to fly. I can’t imagine the toxicity of an environment where someone constantly was calling out other people’s code as being “bad”.