Visit Your Local PBS Station PBS Home PBS Home Programs A-Z TV Schedules Watch Video Donate Shop PBS Search PBS
I, Cringely - The Survival of the Nerdiest with Robert X. Cringely
Search I,Cringely:

The Pulpit
The Pulpit

<< [ May the Source Be With You ]   |  Refactoring Refactoring  |   [ The Eyes Have It ] >>

Weekly Column

Refactoring Refactoring: Sometimes (Even in Computer Programming) What Everyone Knows Isn't Always Correct

Status: [CLOSED]
By Robert X. Cringely
bob@cringely.com

Was it something I said?

Most readers of this column aren’t computer programmers, which means that most readers don’t know how upset I made many coders last week with my crack about refactoring being “ego-based.” They descended on me, these outraged engineers, explaining that I not only did not know what I was writing about, but that I was simply insane. Nothing is new there. But I stand by my words and will now explain them while trying not to alienate the non-technical readers too much. The techies, most likely, will remain outraged.

What the heck is refactoring, anyway? Well, the God of refactoring is Martin Fowler, and here is his definition, stolen straight from his web site, which you can find under the Links of the Week button on this page: “Refactoring is a controlled technique for improving the design of an existing code base. Its essence is applying a series of small behavior-preserving transformations, each of which is ‘too small to be worth doing.’ However, the cumulative effect of each of these transformations is quite significant. By doing them in small steps, you reduce the risk of introducing errors. You also avoid having the system broken while you are carrying out the restructuring -- which allows you to gradually refactor a system over an extended period of time.”

Who could object to that? Refactoring is making code better in an incremental way that avoids creating more problems than it fixes. Ah, but does it really work that way? And does it really help? You see refactoring, in addition to being a clever and very useful tool, is also right now quite a fad in some software development circles. If you don’t refactor, you risk being seen as impure. My objection is less to refactoring than to its overuse. Like Tabasco sauce, a little refactoring goes a long way.

Now here is the important part of this column for readers who are non-technical, but may be signing big checks for software development. Much refactoring is difficult, if not impossible, to justify. If, say, 15 percent of programmer time is being spent on refactoring code, at least some of that time (I might argue 80 percent, as I do below) is being completely wasted. Remember that the next time your CEO calls for a 10 percent across-the-board budget reduction.

The key problem, as I wrote last week, is that refactoring means monkeying with working code. If the program isn’t working, you don’t refactor it. Refactoring is supposed to be IMPROVING code, not fixing it. By definition, you only refactor code that is already working, which where I come from is scary. Working code is a valuable asset since it is hard to get right (at least for me) and takes time. Touching working code is always a risk and so there should be a darned good reason for doing it. Adding features, worthwhile refactoring, or bug fixing are all possible good reasons. Tinkering with code or cleaning it up is not.

Overzealous design or refactoring is just that, overzealous. There is a performance rule that 80 percent of a program's execution runs in 20 percent of the code, therefore you should only have to optimize that 20 percent. In my opinion (he wrote, reaching for his flak vest), time invested in refactoring should work the same way. What is the chance the code you are refactoring will be modified by some future programmer? Does the 80-20 rule apply here, too? If you spend an hour refactoring some code, will you save more than an hour in future code maintenance? If not, then the refactoring is simply not justified on any level.

Programmers who know the behavior of their applications probably know where the performance, bug, and maintenance hotspots are; adding love to those sections is a good investment. Optimizing and refactoring code that sits forever in the shadows only makes you feel good.

As one of my more glib friends put it, for many programmers this is probably too much truth to swallow. We’re talking about programming zealotry here and in my experience, zealots don’t want to hear the truth, they want to hear that they worship the one true God. Of course, their response is, "We want to hear the truth, not your lies about other gods."

Refactoring and another related fad called "extreme programming" are new ideas. Their worth is anecdotal and it is arrogant to think that there is only one right way to do it. Extreme programming has competition from many development methodologies. All seem to work to some degree. Testing, quality and organization seem to be underlying themes to all of them. There is nothing inherently wrong with any of this.

But refactoring can mean different things to different people. What we today call refactoring we used to call "changing code." Some readers will of course scream that refactoring has a prescribed set of transforms, many of which are described in great detail in Martin Fowler’s book. But while the word has taken on life, it seems to me that it means generally to "spruce up old code.”

Sometimes refactoring IS justified. It would be easy to criticize refactoring as evidence of poor planning ("If you're going in and changing the way you wrote that code, why didn’t you write it that way the first time?"), but the truth is that projects evolve. Not only are there new features to be added, but as you progress through creating programs, knowledge gained about the total structure gives you new ideas on how to design the code. Going back and doing that in small stages is refactoring. Some official refactoring is trivial, like changing variable names. Some is obvious. One could argue those were oversights in the original coding.

Here is an example of the refactoring misconception from my friend Paul Tyma. Paul, who is the author of both Dash-O, the best Java bytecode optimizer, and Dotfuscator, which does the same things for .NET, has a web site filled with wisdom and poor punctuation. You’ll find it, too, under the Links of the Week button.

Paul was a manager at Morgan Stanley, where his boss established a so-called refactoring team. “This seemed like a bad idea to me,” wrote Paul, “since such a team had to spend ramp-up time to figure out other people’s code (they didn’t write code from scratch, only refactored existing code) then apply refactoring transforms. I was convinced it was a bad idea when a programmer came to me one Monday complaining that someone else had checked out his project from source control. He was apparently halfway through the coding when he left work on Friday. After making some calls, I found that the refactoring team had checked it out and was refactoring his unfinished code. Extreme programming has a mantra that "everyone owns the code." That is, anyone can make changes. That’s fine, but the person who wrote the code still knows it best and is probably the most qualified to refactor, fix bugs, or anything else. Others can learn it, but the author already knows it. And it made little sense for them to learn it and refactor it before he was even done.”

Paul’s boss at Morgan Stanley had the right intent, but he was trusting every programmer at every skill level to not break things, which is simply too scary for me. There are valid reasons for touching working code, and it is up to programmers, customers, and managers to figure out what those reasons are. Also, given that the quantifiable benefits from any given refactoring are, well, unquantifiable makes things even more difficult.

Many software design books say, "See? Isn’t that easier to understand?" Of course it is -- they just spent five pages explaining how it works. But how does this fit in the real world, with real deadlines and real deliverables? Most of the time, if it ain’t broke, don’t fix it.

Finally, I am sorry to report this week the death of George Morrow, one of the early pioneers of personal computing. Morrow started two computer companies of his own -� Morrow’s Microstuff and Thinkertoys (later called Morrow Designs after the lawyers for TinkerToys objected) -- and his computer designs were also built by Osborne Computing and Zenith Data Systems. George was audited by the IRS, and the agent used a Z-171 computer that George designed. The computer failed halfway through the audit, so George fixed it.

An engineer to the core, George once showed me in excruciating detail exactly how his colostomy bag functioned.

I miss him already.

Comments from the Tribe

Status: [CLOSED] read all comments (0)