Refactoring is the process of changing a software system in such a way that is does not alter the external behavior of the code yet improves its internal structure. The idea of improving an already written code is appreciated in most Agile teams. After all, continuous improvement is is something that these teams strive for. However, improving the already existing code involves time and money. Is it worth it?
Refactoring involves costs, these are
- Cost of Doing the Refactoring
- Cost of Testing the Change
- Cost of Updating Tests and Documentation
It also has the risk of introducing new bugs into the system if the Unit tests and the test harness is not upto the mark. On an XP project, this risk is low assuming that there are good unit tests. On the flip side, there are several advantages offered by refactoring,
- Adding new features does not corrupt the system structure
- Improves understanding of the system
- Easier to test
- Easier to find, isolate and fix bugs.
What are the parameters that should affect the refactoring decision?
John Virgolino suggested that it should not be complex math to show the monetary benefits of refactoring,
You shouldn't have to do a complex business analysis, keep it simple. How much time will it take to refactor and multiply that by an hourly or daily cost factor.$60000 Salary x 1.25 = $75000 burdened cost
$75000 cost / 12 months / 22 working days = $297.61 (Cost per day)
Now, 3 days to refactor the code x $297 = $891 refactoring cost (This is your investment)
On the next code change, It takes 5 days to work the code WITHOUT the initial refactor (5 x $297 = $1485) If takes 1 day to work the same code that WAS refactored (1 x $297 = $297)
$1485 - $297 = $1188 (Savings) - $891 (Initial investment) = $297.00 overall savings
At this point, the investment has paid for itself, and any future savings are gravy and can be used towards productivity on other products, projects, documentation, billable work, etc.
Doing a similar quantitative analysis Simon Johnson suggested there has to be a certain percentage increase in productivity post refactoring for refactoring to justify the cost. According to Simon,
For refactoring to be a better investment than just banking the cash, you have to improve productivity by 5-8% or more. This is quite a big ask and I have big doubts this can be achieved in practice. If your opportunity cost is much higher than the figures represented by "Account B" then you're probably best spending the money on something else, like new features or defect reduction techniques.
However, apart from cost, there could be other reasons due to which refactoring might not be a viable strategy.
Mark Needham commented on the refactoring dilemma citing the case of projects where the deadlines are tight. Team would not see any returns on the refactoring effort if they started at a given point. Mark suggested that though there are several benefits of refactoring however, he has seldom seen delivery dates being pushed out just because refactoring would make it easy to maintain code in the future.
Likewise John too presented scenarios where refactoring might not be an option,
Generally speaking though, management may also have a very good reason not to refactor. It might have nothing to do with money or time, it could be a strategic decision or even a contractual reason you are not aware of (i.e. government work). Make sure you know all the whole story too. I also see a lot of people talking about doing it on your time. This certainly shows conviction and love of your craft, but I wouldn't do it in a vacuum. I have seen programmers do this and cause havoc for other team members and the project as a whole.
Mark also suggested that sometimes the lifespan of the project might be too short-lived to invest in refactoring. Investing in refactoring for such a project might be a futile excercise.
Hence, though there are definite benefits involved in refactoring, the decision to refactor or not, at a given time, in a given context has to be taken with caution. The key lies in weighing the benefits and then taking a call which adds the highest business value.