Why you should allow time (and pay) for refactoring of code

At Radio NZ we engage outside contractors to help us build the web applications we use. The most public of these apps is our website, and internally there is a large database system that is used company-wide.

One of the challenges of writing code is that over time the codebase tends to become rundown. This can be made worse if many people are working on that code. Differences in coding styles, changes in best-practices over time, current (and past) fashion; these all contribute to software rot.

That is not to say that the code was bad when it was first written, or that the original developer did not know what they were doing. Most likely, they did know what they were doing at the time, based on what they knew at that time. Perhaps there were other contraints (such as limited time). Someone did there best, at the time.

Refactoring is a critically important part of maintaining a software application.

Wikipedia describes refactoring:

Code refactoring is a "disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior", undertaken in order to improve some of the nonfunctional attributes of the software. Advantages include improved code readability and reduced complexity to improve the maintainability of the source code, as well as a more expressive internal architecture or object model to improve extensibility.

It goes on to quote Joshua Kerievsky:

By continuously improving the design of code, we make it easier and easier to work with. This is in sharp contrast to what typically happens: little refactoring and a great deal of attention paid to expediently adding new features. If you get into the hygienic habit of refactoring continuously, you'll find that it is easier to extend and maintain code. — Joshua Kerievsky, Refactoring to Patterns

Some will say, "if it ain't broke don't fix it".

Apply that to your car or your house and gardens and see where it gets you. Where it gets you is: broken down in the middle of nowhere, and your phone battery is flat because who needs to charge those things anyway. Or a house that has to be re-clad because you did not repaint it early enough, and the garden, well, I think we have all seen those.

Your code is a valuable asset. It contains business logic - knowledge about how things should work that have been built up over time, and codified in the software. You paid for the process that converted that knowledge to code.

The source code repository also contains (or should contain) business intelligence about why certain decisions were made, and the evolution of the code over time. This is vital information for future developers. If you do not have a code repository, please look for another field of work. Now.

Refactoring has a cost attached. It takes time. But at its core, refactoring is about reducing future costs.

You must accept the cost of refactoring, and make time for your developers to do this work.

The benefits are twofold:

1. Better quality code that costs less to maintain over time.

2. Your staff will be more productive.

On point two, everyone wants to have pride in their work. For programmers, refactoring code is a key part of the process of remaining connected to the code, and experiencing joy in their work. Many studies have shown that happy staff are more productive, on top of the gains of working with quality code.

At Radio NZ I encourage the developers who work for us to suggest refactorings, and I allocate the time for them to do the work because I see this as an investment in the future. The person who has to maintain this code might be me. Or it might be you. 

Forcing people to continue to work on code they know could be improved without letting them make those improvements is bad management.

Some of the code in your system will be hard to refactor. It is probable that this code was put together quickly, possibly without tests. Don't let this put you off. Read and understand the concept of technical debt.

Also, watch this excellent presentation where Katrina Owen refactors some code that has no tests. Watch it a second time if you don't quite get it. If you are technical, read Martin Folwer's book.

If you use Ruby and/or Rails read the book Practical Object-Oriented Design in Ruby. The approach outlined in book has fuelled many refactorings in our projects.

On point about tests. Having good tests is necessary to facilitate refactoring. Without tests you have no way to know for sure that the refactored code behaves the same as the original code.

Chances are, if you don't already have good tests, you will already being seeing application errors after changes to the code, and that these will be hard to find and fix. You'll also see new bugs appear as the direct result of fixing an existing bug. Yes, just like Novapay.

I suggest you do three things:

1. Right now, go and ask your key developers, is there some part of the application that is wasting their time and should be refactored. Get an estimate of how much time is required, and schedule it.

2. Start a discussion with your developers about the overal design of the app. Does it support where the business is now? Is it making future enhancements difficult, or reducing productivity and/or job satisfaction?

3. And more broadly, find out from from each of your developers three things that they feel make it hard for them to produce quality work. Don't put your own definition on quality, just ask the question. Make a commitment to fix these things.