What's wrong with developers?

The author of this article seems to think that refactoring is only used to clean up messes created by bad programmers. He completely ignores one of the major uses of refactoring, which is to evolve a code base so that new functionality can be added to it. No matter how well-written a piece of code is, it will need to change to support new requirements that couldn't have been predicted at the time it was written. (gregjor's excellent earlier comment goes into this in more detail.) Any successful software application that survives more than a few months will need to undergo this kind of evolution. Think of all the features that have been added to Amazon.com or Facebook since these sites were launched. The fact that Amazon's original architecture from 1994 didn't support streaming videos doesn't mean its developers were inept - there was no such technology at the time.

Also, even good programmers can write bad code if they're under time or cost pressure. For example, if your aim is to quickly launch a startup with limited funds, you might cut corners on code quality and scalability, intending to clean up the code later if the business achieves market traction and positive cash flow. At that point, knowing some of the subtleties of refactoring technique could be very useful.

Software is not the only technology that turns legacy and needs refactoring. Have you ever done a significant remodel on a kitchen or bathroom? Did you curse the original plumbers and electricians for not anticipating you would tear a wall out and move the sink? No. You factor those costs into the job, expecting that some things will not be as easy as they first appear. If you hired a contractor to remodel your bathroom and he saw "legacy" plumbing that made the job harder, would you let him tear the house down and start over?

Programmers tend to think of software very narrowly: the things they value are performance, an abstract notion of elegance, how impressed their peers will be by the code. They may try to anticipate future requirements but they risk violating the YAGNI principle if they get carried away (to say nothing of overrunning the budget and schedule).

The people who pay for and use software have a different set of requirements. In most real businesses the data that runs the business, usually living in a relational database management system, has more long-term value than the application software. Data has a longer lifespan than software in most applications, too. Yet many programmers who bang the "legacy code is shit" drum give very little thought to data integrity or the long lifespan of critical business data.

Sometimes legacy code is crap that has outlived its usefulness, and is now too expensive or dangerous to keep tinkering with. More often the legacy code works and isn't really that bad, even if it uses spaces instead of tabs, or has funky variable names, or isn't written in a cool language. Programmers need to step back from their own fashions and prejudices and spend some time figuring out the legacy code and how to fix and refactor it. Almost all of my consulting clients come to me after they've been told by three or four other consultants that their code is so bad it has to be thrown out and rewritten (in some cool new language). That is almost never necessary in my experience.

I've written more about maintenance programming on my blog.