Freelancer Interview: Taking Over a Legacy App

In this guide I interview a freelance developer that I have a tremendous amount of respect for, Derek Harrington. In fact, when I decided to launch devCamp, I had to let go of a number of my freelance clients. And Derek was who I handed the majority of my clients to. Based on my experience with him through the years I knew he would take great care of the clients and that they would be pleased with his expertise.

In this guide I ask Derek a few question related to freelancing. Specifically we discuss practical tips for taking over a legacy application.

Practical Tips for Taking Over a Legacy Application

What is the first thing you do when you take over a legacy application?

Write tests. When you identify the pieces of the code that need refactoring, write specs first to cover the functionality of the feature, then refactor the code and ensure your tests still pass.

What other practical tips for taking over a legacy application that have worked for you in the past?

In evaluating a legacy codebase, use the previous developer if you have access to him/her. Lean on them for info. Ask questions like “what would he do differently?”, “what bits of code did he really want to refactor but never got around to it?”, “what part of the code is he/she the most proud of?”. Lean on their experience to help guide your evaluation. Many times bad legacy code isn’t so much the result of an incompetent developer, but of poor project management and deadline-driven developer pressure.

What are your thoughts on refactoring a code base vs starting over from scratch?

Resist the need to rewrite everything so it’s perfect. We’ve all inherited some nasty codebases and if we’re going to be honest about it, we’ve all been that culprit more than once in our careers. But don’t rewrite for the sake of rewriting. That’s irresponsible.

If you’re going to re-write from scratch, make sure you’re doing it for the right reasons. We all want to work on brand new projects using the most recent versions of every new technology framework. It’s much more enjoyable. Sometimes it’s not the best thing for the project and the client though. Make sure your decision is justified by more than “you wanting to do it”. Sloppy code can be cleaned up. Tests can be added. Versions can be upgraded. Old code with poor app architecture riddled with brittle, unstable features and a failure to use any general best practices or third party tools can be a good justification for rewriting. Lack of understanding of a confusing app is not a justifiable reason.

When is the best time to work on fixing poorly written code?

Just like re-writing an application from scratch, it’s irresponsible to leave messy code that every developer on the team is going to touch. There’s a time to let bad code be. But not when you’re tripping it over it every time you work on the app.