3 ms·
This has been my experience. Carving out time for refactoring explicitly is only beneficial when your stakeholders, PM's, etc. understand its importance complet
by 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 agoIn 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 agoEvidently the answer is refactoring during meetings. /s
- ShamelessC 7y agoSarcasm 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.