Page 1 of 1

Repair / Maintenance of Legacy Code Consulting

Posted: Thu Feb 05, 2009 9:11 pm
by Ollie Saunders
I've been considering starting to work as consultant specializing in taking on bodies of legacy code (PHP, Ruby or JavaScript). I would market myself at companies who are facing the prospect of having to rewrite something in order to get it to do something. Rewriting is financially a stupid thing to have to do, a load of work for zero new functionality.

I was wondering what people think of such an idea. Could people offer any advice.

I'm going to start by taking an old project of mine, that I wrote back when I knew nothing about the importance of code quality, and try to subtlety improve it and add functionality without rewriting.

Re: Repair / Maintenance of Legacy Code Consulting

Posted: Fri Feb 06, 2009 11:30 am
by alex.barylski
Rewriting is financially a stupid thing to have to do, a load of work for zero new functionality.
Refactoring can only take you so far, realistically, before it becomes a rewrite.

I would be careful what you agree to, you might very well end up re-writing it. That being said, people will associate refactoring with *way* lower cost than rewriting, so you better be sure of what your getting into.

Have a sequence of steps hammered down and charge by each iteration:

1. Refactor SQL in table data gateways
2. Refactor busines logic and TDG into model(s)
3. Refactor (X)HTML into external templates/presentation logic
4. Refactor request handling into controller(s)
5. Refactor sub-systems into independent objects (request, response, registry, router, uri, etc)

Once you have completed the 5 steps above, you will have essentially re-written the application. The key is to communicate with the client and discover where they are having the largest issues and maintenance/growing pains, etc.

I typically find that above sequence the most effective, but it's possible to start at the other end and work in the reverse direction, it really would depend on how complex the client code is.

Also remember that refactoring is not about adding features, it's about repairing it's design/interface not it's implementation, although many times you will fix bugs inadvertently while refactoring. Cleaner design has a tendancy to solve problems caused by heavy depenencies, etc.

The hard part is finding businesses willing to pay you to 'refactor' their code. It's not money code, no new features, so half your time should be spent refactoring the code and the other half adding money code.

Make sure to make this clear, otherwise your clients will assume they are essentially hiring you to develop source code and it doesn't sound like you want to just write code?

An excellent approach would be to start with a totally forign project, like WordPress (which badly needs refactoring/rewrite) and go through the phases of refactoring I mention above. When the codebase is finished, release it to the public and when you have a fraction of the bugs, security holes and performance nags, you can demonstrate how effective your design skills are and then, I am sure you will get a ton of bites.

Cheers,
Alex