> It's the developer giving an analysis of the cost and benefit of a refactoring (it will take X time, but will save Y work in the future). And the manager factoring that into all the other circumstances, and deciding whether it's worth the current cost.
I don't think either devlopers or managers can estimate future savings in most cases, but I still think it's necessary to refactor just to not drown in complexity and slow down overall development speed.
My approach is to reserve about 20% for refactoring and technical improvements and let the team decide internally what to use it on.
I don't think either devlopers or managers can estimate future savings in most cases, but I still think it's necessary to refactor just to not drown in complexity and slow down overall development speed. My approach is to reserve about 20% for refactoring and technical improvements and let the team decide internally what to use it on.