Estimating refactoring efforts

Question

Is there a way to estimate a refactoring effort? For instance, we know the lines of code that are duplicated across classes/packages. Now how do we estimate the effort that is required?

Answer 1

At a high level, an agile team (which is my usual environment) would estimate a refactoring story the same way they'd estimate any story: as a group, review the facts of the story (which in this case would include the duplicated code report) and make an intuitive estimate of how long it would take to do the work in whatever units they normally use (story points or actual time). If the story could be completed (implemented and delivered) in pieces, they'd break the story up into one story for each piece and estimate those. (In this case, perhaps there could be one story for each different duplicated block of code, or classes of different duplicated blocks of code.)

This is obviously not exact, but it's usually not bad for small stories, and it takes full advantage of the team's knowledge of the code. If the team doesn't know the code well yet, their estimates will be less accurate.

To estimate a refactoring effort for an entire codebase,

• base the estimation either on code quality reports for the entire codebase, or on manual reviews of sample sections of the codebase plus extrapolation
• write stories for each known problem, estimate them, and add the estimates

Technical debt itself makes estimates less reliable (that is, makes them too low), since when there is technical debt that you know about there is usually more technical debt that you haven't identified. As with any project, if having an estimate is valuable, revisit the estimation periodically to take account of what you learned from work done thus far.