Selling Management (or Yourself) on Refactoring

for RuBoard

One of the toughest things about refactoring is getting people to buy into it. Management tends to frown on changing code that "works" regardless of how dreadfully bad it may be. There is an inherent myopia that seems to afflict all but the most seasoned of coders: "If it ain't broke, don't fix it" is the common response you'll hear when suggesting that a piece of code would benefit greatly from internal improvements. Another is: "Can I sell that to the customer?"a rhetorical question meant to point out that the customer would not even be aware of any internal refactorings that you, in your compulsive zeal, might wish to implement. The fundamental point that both of these arguments miss is that code that is difficult to understand or difficult to enhance is broken and will affect the customer indirectly if not directly. How so? What happens the first time the customer wants what should be a very simple change, but one that is needlessly complex because of the poor manner in which the code was constructed ? Often, what happens is unacceptable to most users: long delays, buggy releases, reduced functionality, and so forth. Crappy code has a sinister tendency to float to the top at the most inopportune moments, usually during a demo for an important client or in the middle of a weekend -long batch run at month-end. The fact is, code that is difficult to understand is difficult to extend and maintain, and code that's difficult to extend and maintain is difficult code. It's that simple. It is broken, whether you realize it or not.

Recently, I had a discussion along these lines with a coder on my development team. A customer had called and complained about a particular portion of one of our products being terribly slow. When we investigated the problem, we tracked it down to some SQL code that this particular developer had written. The code was already in production and had been for years , so he was reluctant to change it. When it became obvious that it had to be fixed, I agreed to take on the task because I was the more experienced SQL developer. I discovered the problem with the SQL fairly quickly, wrote a query that performed much better, then changed the application code to use it. This did two things: one good and one not so good. First, it sped up the query tenfold. The new query ran in a fraction of the time of the old one. This was a good thing. However, the side effect was that the change broke three other pieces of unrelated code. It turns out that there were undocumented, illogical dependencies between methods in this particular class. Three other methods were constructed so that they depended on the SQL in the original method being constructed in a very specific way. Even something as insignificant as inserting a carriage return into the original SQL would have caused them to fail. Recoding the SQL to use my faster approach broke them outright .

On seeing this, it was obvious to me that these methods needed to be refactoredvery badly . My cohort wasn't so sure. He began by hacking (I mean this in the pejorative sense of the word) together a solution that allowed the dependent methods to think that the SQL code hadn't changed. When I suggested that what he should really do is refactor the methods so that they didn't have illogical dependencies on one another, he resisted me pretty strongly. "It compiles," he said. "It does what it's supposed to."

And he was right: It did compile, and compilers don't know or care when they compile ugly code. But, as I explained to him, when we change a system, people are usually involved, and people do care. Writing code that a computer can "understand" is not terribly difficult, because the computer never really understands it in the way that humans do. It just slavishly compiles and executes it. It has no sense of what it's actually doing; it's a machine. Conscious beings like us need a little more than that. We need something that's coherent and logical. We need something that makes sense. As Martin Fowler ^[10] points out, any idiot can write code a computer can read, but it takes a good programmer to write code that humans can read.

^[10] Fowler, Martin. Refactoring: Improving the Design of Existing Code . Reading, MA: Addison-Wesley, 1999. Page 15.

After some "discussions" back and forth, I finally wore him down and he refactored the code as we'd discussed. When he finished, he told me he was glad he'd done it, and, whether he knew it or not, he'd just become a better developer for it.

Note that refactoring doesn't have to be something for which you hold up a development effort. Most refactorings are fairly quick to implement. As I've said, the typical refactoring is a small change followed by an automated test. Because changes are small, they're quick to implement, and bugs introduced by them are easy to catch. Refactoring is something you can and should do regularly during the course of your main development work. Kent Beck compares this constant alternation between the two tasks to "switching hats." ^[11] It's something you'll do frequently while programming, so the analogy is a good one.

^[11] Ibid. Page 55.

Even in situations when refactoring is weighty enough to require a temporary suspension of your main development effort, the time you will save over the long run will make it worthwhile. Unless shipping is imminent, refactoring is not something you should put off because you don't have the time. ^[12] On the contrary, if you feel you don't have the time to refactor, chances are that you need to refactor all the more in order to loosen the schedule a bit through the efficiencies gained by refactoring. Poorly designed code usually takes more code (and therefore more time) to do the same things. Getting rid of it will help you complete the rest of the schedule more efficiently . In other words, you'll run the marathon a lot better if you take the time to get in shape before the race. When dealing with fat, bloated code that has gradually lost its shape over time, what you don't have time for is not to refactor.

^[12] Ibid. Page 66.

The bottom line when selling management or other developers on refactoring is that refactoring saves time, often lots of it. It will also save your sanity , and make those who have to work on the code happier in their jobs because very few of us like to work on junkeven our own. If it's difficult to figure out what to change or where to change it, or if making a change breaks unrelated code, there's a good chance that someone on your team will make a mistake and introduce bugs into your app. The way to minimize such things is to constantly and consistently refactor your code. Hopefully you'll have the autonomy and trust from your superiors to do what you feel is necessary to accomplish the tasks you've been given. This is a simple matter of the Powers That Be delegating authority and responsibility together, as they always should be.

Refactoring is also a teaching tool that will directly affect your own coding practices. You'll learn from your mistakes and those of others, and, slowly but surely, get closer to the ideal of writing code that doesn't need to be refactored immediately. You'll develop a certain intuition for putting software together that is a direct by-product of your experiences cleaning up coding messes and revisiting poor designs. Refactoring will never become obsolete, but you will definitely become a better coder the first time around because of it. Surely management and your fellow coders will see some value in this.

You could also try relating horror stories of projects that failed because they were too complex to extend, maintain, or tune to acceptable performance. There are plenty of case studies in the trade rags from which you could draw (perhaps you can even draw from your own experiences). There's nothing like a little fear to bring the naysayers of the world around.

And if all these tactics fail to sway management that refactoring is worth the trouble, refactor anyway, then take Martin Fowler's advice and don't tell them!

for RuBoard