4 ms·

Good article and a good inspiration to debate this topic. Honestly I already get in a bad mood when I read this conversation with the PM - this mentality "We ne

by nisa 4y ago

Good article and a good inspiration to debate this topic. Honestly I already get in a bad mood when I read this conversation with the PM - this mentality "We need to timebox that activity so it does not swallow the time that should go to features and bug fixes." - depending on the tech debt and state of the codebase devs are wasting enormous amounts of time working around stupid issues (i.e. tech debt) and even a little bit of team effort might help - there is maybe some company out there where someone argues for rewriting the almost bug free haskell code to use higher kinded types and lenses because at the moment it's not so looking well but I guess in reality often there is just a lot of shitty cruft in java/javascript land that a few weeks of thinking and fixing (in the team, with lot's of discussions) improves much more and gives more time for features than avoiding that.

zdragnar 4y ago
This is one area where velocity tracking actually helps PMs understand what you're talking about. If you follow the "boy scout" rule of leaving every file a little better every time you touch it, you will be slowly cleaning up debt while also slowing down velocity. If that is not an acceptable trade-off to the PM, then they need a proper estimate for what the cleanup will take- that's the armor they have to shield you from shit raining down from higher levels when someone wants to know why the new feature timeline is being delayed. If your tech debt is so bad it can't be incrementally improved, then it can usually be reframed as building a new version of feature X when really you're just rewriting it. Sell it as a performance / stability improvement and voila, it can be prioritized appropriately. If you have tried all of the above and your work priorities are still being dictated, either the company is in a tight spot (contracts require features on a tight timeline) and you need to muddle through until the next phase, or the company isn't regarding you as a professional and it is time to move on. No skilled tradesman worth their salt would let management tell them not to clean the shop because that takes time away from building things. The professional dictates the work practices.
- deleted 4y ago
  [deleted]
megablast 4y ago
> We need to timebox that activity so it does not swallow the time that should go to features and bug fixes it is probably more so that they can still have good estimates. If you start introducing new work that has no time limit and no timebox, it can push out your estimates.

by nisa 4y ago

zdragnar 4y ago

This is one area where velocity tracking actually helps PMs understand what you're talking about. If you follow the "boy scout" rule of leaving every file a little better every time you touch it, you will be slowly cleaning up debt while also slowing down velocity. If that is not an acceptable trade-off to the PM, then they need a proper estimate for what the cleanup will take- that's the armor they have to shield you from shit raining down from higher levels when someone wants to know why the new feature timeline is being delayed. If your tech debt is so bad it can't be incrementally improved, then it can usually be reframed as building a new version of feature X when really you're just rewriting it. Sell it as a performance / stability improvement and voila, it can be prioritized appropriately. If you have tried all of the above and your work priorities are still being dictated, either the company is in a tight spot (contracts require features on a tight timeline) and you need to muddle through until the next phase, or the company isn't regarding you as a professional and it is time to move on. No skilled tradesman worth their salt would let management tell them not to clean the shop because that takes time away from building things. The professional dictates the work practices.

deleted 4y ago
[deleted]

megablast 4y ago

> We need to timebox that activity so it does not swallow the time that should go to features and bug fixes it is probably more so that they can still have good estimates. If you start introducing new work that has no time limit and no timebox, it can push out your estimates.