Editorial Note: I originally wrote this post for the NDepend blog. You can find the original here, at their site. While you’re there, take a look at some of the other posts and announcements.
I’ve trod this path before in various incarnations, and I’ll do it again today. After all, I can think of few topics in software development that draw as much debate as this one. “We’ve got this app, and we want to know if we should refactor it or rewrite it.”
For what it’s worth, I answer this question for a living. And I don’t mean that in the general sense that anyone in software must ponder the question. I mean that CIOs, dev managers and boards of directors literally pay me to help them figure out whether to rewrite, retire, refactor, or rework an application. I go in, gather evidence, mine the data and state my case about the recommended fate for the app.
Because of this vocation and because of my writing, people often ask my opinion on this topic. Today, I yet again answer such a question. “How do I know when to rewrite an app instead of just refactoring it?” I’ll answer. Sort of. But, before I do, let’s briefly revisit some of my past opinions.
Getting the Terminology Right
Right now, you’re envisioning a binary decision about the fate of an application. It’s old, tired, clunky and perhaps embarrassing. Should you scrap it, write it off, and start over? Or, should you power through, molding it into something more clean, modern, and adaptable. Fine. But, let’s first consider that the latter option does not constitute a “refactoring.”
A while back, I wrote a post called “Refactoring is a Development Technique, Not a Project.” You can read the argument in its entirety, but I’ll summarize briefly here. To “refactor” code is to restructure it without altering external behavior. For instance, to take a large method and extract some of its code into another method. But when you use “refactor” as an alternative to “rewrite,” you mean something else.
Let’s say that you have some kind of creaky old Webforms application with giant hunks of gnarly code and logic binding the GUI right to the database. Worse yet, you’ve taken a dependency on some defunct payment processing library that prevents you from updating beyond .NET 2.0. When you look at this and say, “should I refactor or rewrite,” you’re not saying “should I move code around inside this application or rewrite it?” Rather, you’re saying, “should I give this thing a face lift or rewrite it?”
So let’s chase some precision in terms here. Refactoring happens on an ongoing and relatively minor basis. If you undertake something that constitutes a project, you’re changing the software. You’re altering the way it interacts with the database, swapping out a dependency, updating your code to a new version of the framework, etc. So from here forward, let’s call that a reworking of the application.