Jul 10, 2007 / software
Should your clients pay you to Refactor?

As we all now know, Refactoring means "improving code". This can be something as simple as renaming a function to make it more readable, or something less simple like building a class structure so you can use polymorphism instead of conditional statements. I also tend to overextend the use of the phrase "Refactoring" and let it include other activities, such as formatting and indenting code so that it looks pretty, deleting old files, and other menial spring cleaning tasks.

Lets face it, doing all this stuff takes time, and time costs somebody money. More often than not, it costs our clients money (or our boss), and I'm not sure they like it!

Something tells me that my clients don't really want to pay for code cleaning. I recall once saying to a client "I've only implemented 1/2 of the features today because I felt I needed to spend some time cleaning up the the code which was getting a bit scruffy". The clients response wasn't one of great appreciation, I think they would have preferred that I just wrote more features and didn't bother using expensive man-hours to clean code. Anyone been in this situation?

In fact, before I was a consultant, I recal trying to explain the act of Refactoring to my boss. I didn't sell it very well because I hadn't used it enough to appreciate the benefits. The final consensus was that refactoring was an unnecessary luxuruy that we didn't have time for with our commercial, deadilne pressured projects.

At one time I used to think that they were probably right, and that I was being a bit naughty using this time learning to clean up code. Now I see it very differently:

If you only occasionally refactor your code, there will never be a good time to do it.

If you're working with a living code base that is growing and changing, then at some point you'll have to clean stuff up to keep working with it. If you don't refactor and tidy as part of your routine, then this job is going to get bigger and bigger, and more and more expensive to do as a "one-off". So I've decided that, as a professional and responsible software developer, I'm happy to take time to...

refactor and tidy code all the time.

Clients can't reasonably complain if you do it like this. It's a bit like saying that you don't want to pay your window cleaner to go up and down ladders, you just want them clean windows! If you realise that refactoring is a necessary activity, then it's never time wasted.

So, I reckon that yes, clients should pay us to Refactor, because it's a necessary part of the job and is in the best interest of the project.

Some other random observations that may help:

  • Tidying and refactoring gets cheaper the more you do it. Like anything you get better at it.

  • If you're working on an untidy code base, then consider allowing for this when making time estimates for coding tasks. However, rather than quoting for a sweat inducing 100 hour task of "Refactoring", see it as more of an environmental variable that will increase the overall time needed. So, just as you might add a 7% cost increase because the team is working with unfamiliar technologies, you might also chose to add a 5% cost increase because the team is working with a code base in need of refactoring.

  • If you're in a team, don't spend time refactoring other peoples work because they can't be arsed. You'll be fighting a losing battle and that kind of "time wasting" gives the practice a bad name IMHO!

  • Refactoring is much much safer when done against unit tests, and preferably a version control system for rollbacks. However, I think that even if these facilities aren't available to your project (god knows why!) then still try and keep things in order but perhaps go easy on some of the bolder refactorings.

  • If you're working on throw-away code you should still Refactor relentlessly, because 90% of throw-away code doesn't get thrown away!

Thoughts welcome!


You may also like...