Viewing a single comment thread. View all comments

Kriemhilt t1_iycsjrt wrote

The normal term for "the burden of working with rubbish code that is hard to understand or change" is technical debt.

One of the advantages of calling it that is that it sounds sort-of like financial debt, so you're putting it in language management might find easier to understand. You ideally want some concrete motivation though, like

>"technical debt will make it slower (and therefore more expensive) to add these features you want, but if we invest in reducing our technical debt first, those features will arrive sooner and have fewer bugs."

If they don't have any bugs to fix or features to add, this obviously doesn't help you much!

4

OldHellaGnarGnar2 t1_iycyqk2 wrote

Good advice!

>If they don't have any bugs to fix or features to add, this obviously doesn't help you much!

But that's the issue I think I'll have if I try to push it. Our robots generally just work as-is, and most of what we have to add is parameterized, so we're mostly filling in variables and not actually writing code. Actually writing new code for bug fixes or new functionality is pretty rare (I think I'm the only one that's learned how to do it since our division implemented robots).

About a year ago (first time I actually wrote new functionality for them), my boss and I had to convince management I was capable of adding in a new safety feature that got brought up as something we should do.

2