The Decision to Refactor

Posted by Vikas Hazrati on Jun 15, 2010

Sections

Process & Practices,

Architecture & Design,

Development

Topics

Agile Techniques ,

Agile ,

Programming ,

Refactoring

Share |

RELATED Research

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.

RelatedVendorContent

Five Key Practices to Agile ALM

Agile Practices to Improve Project Management Organization (PMO) Effectiveness

Agile Maturity Model Applied to Building and Releasing Software

Agile assessments for your team

Agile workshops and training

Related Sponsor

Maximize your business-responsiveness with Mingle. Provide your global development team a shared space that adapts to the way they work.

1. Back to top

   Technical Debt

   by Pete Gosling

   This is a bean counter's narrow view of refactoring ! The article recognizes there is a cost to refactoring, but doesn't appreciate the impact of technical debt building up over time. Each time refactoring is put off, it makes many of the subsequent features, bug fixes and later refactorings more expensive. If we're taking a bean counter's view, then technical debt should be treated like compound interest ! It adds cost to all subsequent work, not just the next feature. Refactoring is just something that developers should do, as professionals, in the much the same way that other craftsmen clean up at the end of their work.

   Reply

2. Back to top

   Re: Technical Debt

   by Niclas Lindgren

   I fully agree, I can't believe we are still debating this issue. Refactoring can be viewed a lot as putting all yours tools back in order in your workshop before working on the next item. Making sure your spare part stock isn't stopping your pipeline flow.
   
   Not doing it refactoring, thus not caring about your code base, has a much higher costs than can be anticipated, not having complete test harnesses up, with automated test that does not require changes when doing refactoring is just plain professional practice, how else will you keep the pace up and the bug reports down. As soon as you stop doing all these good practices you suddenly see that getting a release out of the house suddenly doesn't take hours it goes into days than into weeks and even worse maybe even months of "stabilisation" as it used to be called.
   
   Suddenly your workshop floor has no clean surfaces, no shelves to offload stuff on, no gas tubes for the welds and no garage doors that open. And all this happens in weeks, not months or years, it is just so gradual that people forget what things used to be like when the code base was nimble and agile. It is a lot like aging, you don't see it yourself in the mirror, but everyone else does.

   Reply

3. Back to top

   Re: Technical Debt

   by Niclas Lindgren

   Forgot to mention, when this slow of increasing workload happens, suddenly talk begins about expanding the team, because "we don't have time", so you add more people to handle the additional workload which is a dramatic cost increase and productivity inhibitor, slowly you get into a bad spiral, adding more people, creating more "work" that needs more people (you think).
   
   Also management should not have any other agenda, they should provide their developer with the entire view, all reasons, requirements and strategies, otherwise they cannot make informed decisions on when to improve certain areas in the code and when to leave for a rainy day.

   Reply

4. Back to top

   Other benefits of refactoring

   by Michael Hunger

   When discussing that, I would also mention other benefits of refactoring.
   
   When dealing with a unknown codebase refactoring can help you to understand the code, its intent and structure. So you refactor to learn about it. It depends on other factors if you will keep the refactored code afterwards.
   
   Refactoring is small steps. But it often leads to a point where a insight about the design pops up. Then a big laps can bring the design forward quite a lot. I often compare that to one of the last puzzle pieces falling into its place and giving a very different view than just before.
   
   And refactoring is an ongoing continuous process. If you keep your technical debt low and follow the boy scout rule, it is not much effort per day (certainly not more than surfing the web during work hours) to steadily improve/keep your code quality.

   Reply

5. Back to top

   Don´t even ask

   by Ralf Westphal

   Who has heard about a phyisician asking "Should I wash my hands before I start the surgery?" or "Should we sterilize the instrument?" Who has heard about a cook asking "Should I clean up the kitchen at the end of the day?" or "Should I sharpen the knives?"
   
   Even starting to justify refactoring is plain wrong. Refactoring need not be brought to the attention of any non-technical management like a Product Owner or a project leader or the customer or the company´s boss.
   
   Refactoring needs to be just included in any estimates. No explanation needed for "why does that take sooo long?"
   
   Never ask permission for doing your job in a professional way. That means: never ask permission for refactoring. If you just refactor as needed from the start on, then there won´t be huge refactorings in the future.
   
   -Ralf

   Reply

6. Back to top

   Re: Technical Debt

   by Dmitry Serebrennikov

   Yes, very narrow view.
   
   In fact, the features added without refactoring will likely themselves create additional clutter and technical debt, simply because there is no good place to add them cleanly. So this truly becomes a compound interest problem, where cost starts to rise exponentially.
   
   And don't forget the cost of demoralized developers.

   Reply