The Refactoring Curve

Tuesday, January 25, 2011

imageEmpirical studies on software refactoring are hard to find, but I believe refactoring follows the 80/20 rule - 80% of the possible benefit comes by applying just the first 20% of effort. Like most work in engineering and economics, the curve flattens under the pressure of diminishing returns. In this context I'm not thinking of individual refactoring operations (like extract method), but overarching efforts to improve software quality through rework, or by following a process like test-first design.

I think most of use could agree that the best place to be on this curve depends on context. Start-up software is different than complex software for a mature enterprise.

Taking context into account - do you feel like you operate in the sweet spot of the curve for your project?

My suspicion is that developers who read blogs feel like their project are always too far on the left hand side of the curve, but I wonder if the business owners feel the same way.


Comments
tobi Wednesday, January 26, 2011
I allow unimportant parts of the code which do not need to change often to become messy and do not hesitate to hack. Every few month I do major refactorings. The batching strategy has been a great success.
gravatar Martin Evans Sunday, February 6, 2011
I think the business owner will only be focusing on how much of the busness need is being solved by the project in it's current state (and rightly so).

As a developer however, I'm always thinking about how easy it will be to implement the next feature. I think this different perspective occasionally contributes to a little friction when scheduling time on development iterations.
Time spent refactoring, may not bring immediate business benefit but will leave the codebase in a much more flexible state to allow new, 'must have immediately' features to be added quickly.

I haven't got the answer to this one!
Comments are now closed.
by K. Scott Allen K.Scott Allen
My Pluralsight Courses
The Podcast!