3 ms·

Resolving tech debt should not be a requirement for completing a task, it should be planned. Such tasks will never be planned because there's always higher-pri

by tremon 3y ago

Resolving tech debt should not be a requirement for completing a task, it should be planned. Such tasks will never be planned because there's always higher-priority tasks to be done. I actively encourage my developers to clean up the code they'll be working on, otherwise you're just piling tech debt upon existing tech debt. The only exception is repository-wide refactorings: if those are necessary to implement a feature, we block the feature and create a prerequisite task outlining the refactoring needed. But this is mostly to aid the review process, in my mind these two tasks are still one (and if I work on it myself, I usually already have the feature half-implemented so I can double-check that the refactoring does indeed make the feature easier to implement).

figassis 3y ago
I agree this is ideal, but my point is, there were instances where you try to cleanup, and you end up pulling an infinite thread because the feature you're working on is stacked on top of 10 other features, each of which were duct taped together, and product forgot about this, and they think if it's working it must be very straightforward to just add this one thing. Your choice is to duct tape again or to refactor the 10 features. So you dare change one like of code that optimizes one of the previous features and the reviewer asks you to also optimize A, encapsulate B and replace method C with new and improved method D that does some of what you need but you now need to rework your solution to conform to that. So I often leave that semicolon alone.
lelanthran 3y ago
> I actively encourage my developers to clean up the code they'll be working on, otherwise you're just piling tech debt upon existing tech debt. While I broadly agree on the boy-scout rule, it can severely throw out (already poor) estimates. It shouldn't be a rule ("always clean up the shit you see when working on something else"), it should be optional ("If it doesn't mess up your original goal, clean up as much as is possible within the estimated time").

by tremon 3y ago

figassis 3y ago

I agree this is ideal, but my point is, there were instances where you try to cleanup, and you end up pulling an infinite thread because the feature you're working on is stacked on top of 10 other features, each of which were duct taped together, and product forgot about this, and they think if it's working it must be very straightforward to just add this one thing. Your choice is to duct tape again or to refactor the 10 features. So you dare change one like of code that optimizes one of the previous features and the reviewer asks you to also optimize A, encapsulate B and replace method C with new and improved method D that does some of what you need but you now need to rework your solution to conform to that. So I often leave that semicolon alone.

lelanthran 3y ago

> I actively encourage my developers to clean up the code they'll be working on, otherwise you're just piling tech debt upon existing tech debt. While I broadly agree on the boy-scout rule, it can severely throw out (already poor) estimates. It shouldn't be a rule ("always clean up the shit you see when working on something else"), it should be optional ("If it doesn't mess up your original goal, clean up as much as is possible within the estimated time").