[mibollma]

> 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.

[cudgy]

Why 20%? Just curious how you arrived at that percentage.

[mibollma]

Thats why I said "about" 20%, so it differs based on project and situation.

Enough to get useful stuff done, small enough to keep most capacity for feature development. Also depends on the amount of technical tickets deemed relevant by the team

[pirate787]

Pareto optimal

[cudgy]

That assumes there are equal weights to the factors.