Legacy projects
Written on December 19 2011.
This blog post was written a long time ago and may not reflect my current opinion or might be technically out of date. Read with a grain of salt.
As a company or freelance developer you have probably encounter the dilemma of taking over somebody else code. On one side you are happy to get new work, on the other side dealing with legacy code can be frightening.
Here are some questions you will need to ask when you continue and maintain a project:
- What kind of client will you get when accepting the project?
- How was the relation between the previous developer and the client?
- Where is the project hosted? Do you have control over it?
- What are the dependencies of the project? Ruby 1.8.6, Rails 1.2? RMagick? Will you have to migrate it to newer versions at some point? Does the client understand that you need to upgrade libraries and frameworks?
- More generally, is the client aware that software needs maintenance?
- Will you be the one responsible for old bugs that are discovered after you took over the project? Usually the client sees a bunch a stuff not working once you start to work on the project.
- Have you considered a code review before accepting the project? Who did it? Someone external? The previous developer (hint: blink in red in your radar)?
- Will you need to implement big new features? How the previous developer used to bill the client for them?
- Is the client aware that you will probably be a bit slower than the previous developer when you start working on the project?
Many of these questions sounds stupid or simple good sense but a checklist is never too much when it comes to such a tricky decision.
Everybody likes to write new code. Maintaining code is usually less appealing.
I love to dig in somebody else code,to refactor it, to understand what the previous developer had in mind when doing it. I like to remove the small imprecisions here and there and to curse when I see useless javascript files or two hundreds lines of commented code.