Get your FREE 30 page Developing SOLID Applications guide!

Help! I’m drowning in legacy code!

It never fails. Someone will write me after reading my book or taking a class with the same story. They were so jazzed: they felt like they were on top of the world, ready to attack their next programming task with vigor! They had studied hard, connections had been made, understandings had been formed. And then, inevitably, reality sets in. They look at their code, same as it was before, and realize: this is going to be harder than I thought.

It can be easy to feel dejected when looking at a pile of code you inherited from four generations of programmer ago. None of the best practices or principles. No tests. Hell, you’re lucky if you even have objects that don’t rely on PHP 4 style constructors. You’re in legacy code hell.

But there’s hope.

Software as a long game

Even though it can feel hopeless when starting at such a massive pile of crap, there is in fact hope. There is a redemption waiting for you. That redemption is found in a simple revelation: software is a long game.

Consider: that steaming pile of detritus you’re working on didn’t get that way overnight. In fact, it took a long time to get a code base that big together in the first place. Code takes time to grow. Rome wasn’t built in a day, and neither was your application.

PHP has been around for a long time, over 10 years. Much of that time, PHP didn’t many of the features that now make it a world class programming language. Add to that the fact that PHP’s low barrier to entry means that best practices we now take for granted weren’t known let alone followed means there’s lots of in production business-critical code that we’re now responsible for maintaining.

What can you do, today?

But everything doesn’t need to be fixed overnight. In fact, it can’t be fixed overnight, so relax.

Writing software is a long process that takes time. It’s okay – in fact, it’s expected, that you’ll take time to make incremental changes. The first step is to make something better, today, that wasn’t better yesterday. Refactor something small. Create a group of objects that talk to each other a little bit more reasonably. Decouple a few small things. Make incremental improvements.

As you move through the code, you have an opportunity to improve each part of it in small ways. Combined with the fact that new additions you make will adhere to current best practices, over time the code will begin to dramatically improve. That’s how you make a difference in a legacy code base – through small, incremental changes over time.

To defend everything is to defend nothing.

And even though it’s easy to be a perfectionist and think “everything has to be perfect”, that kind of thinking won’t get you where you need to go. Frederick the Great told his men, “to defend everything is to defend nothing.” You have to pick and choose your battles. Maybe you can’t refactor the entire database logic section this week. But if you can refactor one model, one controller, one function or one algorithm, you can make steady, incremental progress. And that’s something.

Good luck!

Write better object oriented PHP today.

Object oriented programming always leaves you with a headache. What if you could master it instead?

Get the book now! »

Glen Scott (@glenscott) wrote at 12/12/2013 10:47 am:

I guess I’m part of a rare breed — I actually prefer working with legacy code rather than brand new projects. There’s something immensely satisfying about learning the ins and outs of a project from scratch, getting inside other developers heads and subsequently refactoring as required. I love it!

Good point about picking your battles though — never try and bite off more than you can chew when refactoring or you will get into a huge mess. Best to identify critical parts of the codebase — those that change often — and concentrate your efforts there.

Charlie Jolly (@K_International) wrote at 1/9/2014 12:10 pm:

Using PHP for internal projects, I’m concious that it’s taken a long time to realise that a pragmatic approach is never a bad one.