Refactoring or Rebuilding: Working with Legacy Code

Everyone has some form of Legacy code, and at my new job we have plenty of it. The Deseret News has been around in paper format since 1850, and has had a web presence since 1996. I can still find parts of our codebase for running with Sybase and Vignette. Fortunately, most of the code we work with is much more modern using the latest PHP with an in-house MVC framework. However, there is still one big piece written in a less than ideal system. Its still PHP, but much more hacked together. It is our backend CMS system for controlling the website. It is painful to use, and we get many complaints all the time about it. When I joined the company three months ago, I was told we were going to completely rewrite it. Three months later, the “rewrite” of the CMS is still ages away and we’re continuing to hack to support requested changes.

So I started to put together some plans for the colossal undertaking of re-writing our CMS. The more I looked, the more I realized just how much “stuff” this thing did. There were lots of complex things that we didn’t support anymore, but also complex tools we used on an hourly basis. It would take months before we would be able to replace even the basic core functionality.

Then, on Twitter, I saw a link for a talk Paul M. Jones gave at the Nashville PHP Usergroup. It was entitled: “It Was Like That When I Got Here: Steps Toward Modernizing a Legacy Codebase.” I couldn’t think of a better title for that talk, nor a better talk to listen to at this very moment. It was a light bulb going off saying “Hey, maybe we should take a second look at just fixing up our existing CMS.” If you haven’t watched his talk yet, you need to, it is definitely worth it.

To be honest, the code Paul showed in his slides were 10 times worse than what we have to deal with. The only real reason our old CMS is in it’s current state was the idea of “Hey, we’ll be making a new CMS soon, so we’ll just hack together the bare minimum on this old thing.” So we sat down and had a serious conversation with out team on “Why not just refactor?” Yes, there will be a lot of work and pain involved, but it offered one huge upside: we could iterate and achieve gains right now.

So we’re doing a quick audit of things that are in there we don’t support anymore, and there is a lot. All of that will be removed. Then we’re going to have a list of all the existing functionality and give it to the people who actually use it and have them tell us two things. On a scale of 1 to 10, how painful is this feature to use right now, and then have them prioritize which features they’d like to see fixed first.

As a development team, we’re listing out all the pain-points of developing with the old system. We’re doing the same thing with our list and adding one more datapoint: how difficult to make the change? What will it take to upgrade the old templating system? Can we implement our new framework and have it fall back?

Using these lists to decide what to refactor, we can get the biggest gains for the least amount of work. If we were to rebuild, we would get the smallest gains (if any) of barely having something functional with the greatest effort.

So over the next few months we’ll be refactoring our old CMS, and while it’ll be painful, it will give us a much better end result.