Hacker News Reader

Comment by louwrentius | Hacker News Reader

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.

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.

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?

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

Reply on news.ycombinator.com