4 ms·

Well refactoring should never be a ticket it self. It should be done in order to facilitate, even enable, the construction of a new feature. Perfomance should

by in9 4y ago

Well refactoring should never be a ticket it self. It should be done in order to facilitate, even enable, the construction of a new feature. Perfomance should be a feature request, IMO. If the user can't use a feature, or se a result, due to performance, the should be requested by the PM it self, no? Reliability as well, should fall under the same logic.

eyelidlessness 4y ago
The problem is that some refactors will languish eternally as they don’t serve an immediate feature goal or even a bug fix—even if taking on the abstract refactor work broadly enables whole sets of features and fixes to be done more effectively. In my current work experience, this means having a fairly deep mental model of how a given refactor might impact various seemingly unrelated efforts, and knowing how and why to advocate for them. This advocacy doesn’t translate into a literal ticket (and that’s not how my team manages all work items and their prioritization), but it definitely translates into “I’ve identified a specific unit of work which doesn’t immediately serve these goals, but would broadly improve their velocity and success.” Next to no one wants to hear that kind of advocacy, because their Babel Fish generally formulates it as “stop or slow immediate progress for abstract goal”. But that’s what the debt part of tech debt is: you have to sometimes prioritize getting out of your own way before you can move forward in any direction. As far as performance as a feature and corresponding request, sometimes you need far too much technical detail to even know what to ask for. I’m saying this having just landed an optimization which completely obliterated the existing Y axis on one of our monitoring systems. There was some vague sense of where some of the optimization target might be, if users or even the team were able to make the connection. It took dedicated time just profiling a bunch of fixtures, without anything to go on besides “some stuff is slow, for example ___”, to understand the broader performance story which went well beyond known bottlenecks. Part of being an engineer is, or at least should be, some freedom to dive in to make these kinds of connections independent of specific features and specific detailed feature requests (performance or otherwise). Even if the only “work product” is just a report on what you found, at least it might be cross-referenced for when it does correlate to specifically ordained work items.
- deleted 4y ago
  [deleted]

by in9 4y ago

eyelidlessness 4y ago

The problem is that some refactors will languish eternally as they don’t serve an immediate feature goal or even a bug fix—even if taking on the abstract refactor work broadly enables whole sets of features and fixes to be done more effectively. In my current work experience, this means having a fairly deep mental model of how a given refactor might impact various seemingly unrelated efforts, and knowing how and why to advocate for them. This advocacy doesn’t translate into a literal ticket (and that’s not how my team manages all work items and their prioritization), but it definitely translates into “I’ve identified a specific unit of work which doesn’t immediately serve these goals, but would broadly improve their velocity and success.” Next to no one wants to hear that kind of advocacy, because their Babel Fish generally formulates it as “stop or slow immediate progress for abstract goal”. But that’s what the debt part of tech debt is: you have to sometimes prioritize getting out of your own way before you can move forward in any direction. As far as performance as a feature and corresponding request, sometimes you need far too much technical detail to even know what to ask for. I’m saying this having just landed an optimization which completely obliterated the existing Y axis on one of our monitoring systems. There was some vague sense of where some of the optimization target might be, if users or even the team were able to make the connection. It took dedicated time just profiling a bunch of fixtures, without anything to go on besides “some stuff is slow, for example ___”, to understand the broader performance story which went well beyond known bottlenecks. Part of being an engineer is, or at least should be, some freedom to dive in to make these kinds of connections independent of specific features and specific detailed feature requests (performance or otherwise). Even if the only “work product” is just a report on what you found, at least it might be cross-referenced for when it does correlate to specifically ordained work items.

deleted 4y ago
[deleted]