4 ms·

I always get nervous when “refactoring” shows up on the backlog and then gets deprioritized. In my mind it should never show up as a separate task and then it s

I always get nervous when “refactoring” shows up on the backlog and then gets deprioritized. In my mind it should never show up as a separate task and then it should never get ignored . It should just be a normal part of the workflow for professional development that gets done without much fuzz. Most long term technical debt can be reduced a lot by proactively refactoring small things that for some reason don’t work well. When I worked closer to production the people at the workshops also cleaned and repaired their equipment every evening, crunch time or not. They didn’t just let their machines die long term because it may buy some time in the short term to skip maintenance.

ShamelessC 7y ago
This has been my experience. Carving out time for refactoring explicitly is only beneficial when your stakeholders, PM's, etc. understand its importance completely. Usually, at least one person up the chain says "it's already working and we have more important things to focus on. Put it on the backlog indefinitely." Better to just incorporate refactoring into the estimate for any given coding task and do it without explicit permission. Unless of course you're in a culture that is willing to straight up miss a deadline in order to get refactoring finished.
- Ididntdothis 7y ago
  “Better to just incorporate refactoring into the estimate for any given coding task and do it without explicit permission.” It should be as implicit as attending planning meetings. For some reasons PMs usually have no problem forcing people to sit through meetings but they have a problem with spending the same amount of time refactoring .
  - williamdclt 7y ago
    In my teams we take tickets for meetings, which makes product owners very aware of their impact on delivery. I like including refactoring in tickets, but if the refactor is consequent it's not going to work. It's not so often thankfully, I usually manage to convince the PO of the value of it, then try to not budge once it's decided
  - Archit3ch 7y ago
    Evidently the answer is refactoring during meetings. /s
    - ShamelessC 7y ago
      Sarcasm not needed. I've probably done this during a meeting. I definitely code if it's an all hands on deck meeting that gets hijacked by technical discussions that aren't relevant to my work.
BurningFrog 7y ago
I probably spend 1/3 of my average day refactoring. Occasional there is a bigger refactoring project, but that's my normal day.

ShamelessC 7y ago

This has been my experience. Carving out time for refactoring explicitly is only beneficial when your stakeholders, PM's, etc. understand its importance completely. Usually, at least one person up the chain says "it's already working and we have more important things to focus on. Put it on the backlog indefinitely." Better to just incorporate refactoring into the estimate for any given coding task and do it without explicit permission. Unless of course you're in a culture that is willing to straight up miss a deadline in order to get refactoring finished.

Ididntdothis 7y ago
“Better to just incorporate refactoring into the estimate for any given coding task and do it without explicit permission.” It should be as implicit as attending planning meetings. For some reasons PMs usually have no problem forcing people to sit through meetings but they have a problem with spending the same amount of time refactoring .
- williamdclt 7y ago
  In my teams we take tickets for meetings, which makes product owners very aware of their impact on delivery. I like including refactoring in tickets, but if the refactor is consequent it's not going to work. It's not so often thankfully, I usually manage to convince the PO of the value of it, then try to not budge once it's decided
- Archit3ch 7y ago
  Evidently the answer is refactoring during meetings. /s
  - ShamelessC 7y ago
    Sarcasm not needed. I've probably done this during a meeting. I definitely code if it's an all hands on deck meeting that gets hijacked by technical discussions that aren't relevant to my work.

BurningFrog 7y ago

I probably spend 1/3 of my average day refactoring. Occasional there is a bigger refactoring project, but that's my normal day.