Possible Duplicate:
When is a BIG Rewrite the answer?
Software rewriting alternatives
Are there any actual case studies on rewrites of software success/failure rates?
When should you rewrite?
We're not a software company. Is a complete re-write still a bad idea?
Have you ever been involved in a BIG Rewrite?

This is an area of discussion I have long been curious about, but overall, I generally lack the experience to give myself an answer that I would fully trust.

We've all been there, a new client shows up with a half-complete project they are looking to finish and launch. For whatever reason, they fired their previous developer, and it's now up to you to save the day.

I am just finishing up a code review for a new client, and in my estimation is would be better to scrap what the previous developers built since and start from scratch. There's a ton of reasons why I am leaning toward this way, but it still makes me nervous since the client isn't going to want to hear "those last guys built you a big turd, and I can either polish it, or throw it in the trash".

What are your general rules for accepting these projects?

How do you determine whether it will be better to start from scratch or continue with the existing code base?

What other extra steps might you take to help control client expectations, since the previous developer may have inflated those expectations beyond a reasonable level?

Any other general advice?

  • 2
    One thing I would want to know is why last developer was fired. Was it because it ended up that the client was a pain to deal with and they couldn't get on? I have had that happen :P – Steve Oct 21 '12 at 22:24
  • Determining whether to start from scratch is a decision you'll make after speaking with your client. How far into development are they how much have they spent to get there? And more importantly are they open to have you start from scratch or against it? If they want you to use what they already have just be open and let them know it may take longer it may not be done right but the positive is they'll still be hopefully within budget and get their project completed sooner. And once it's live and generating revenue they can always re-write the code for a v2.0. – Anagio Oct 22 '12 at 10:33

When a project like this comes in, my general rules are:

1) Ask to have complete access to evaluate what has been done.

2) Find out what may be usable, or usable with minimum tinkering (database architecture and design elements often fall into this category).

3) Give an estimate based on salvaging what is usable along with an estimate I would normally give from scratch. This helps me decide whether or not it's better to start from scratch.

I think it's important to be honest. If I feel that what has been done is truly substandard, I need to be able to explain why in simple terms. That's actually somewhat easier these days (not HTML 5, not a responsive design, no consideration for mobile, no use of framework, etc) as the technology has grown horizontally and the bad developers are easier to weed out.

Most of all it's important to make the potential client see what I see and give them the confidence that I not only know what's wrong, but how to fix it. If that means starting over, it's better to bite the bullet and do it now.

| improve this answer | |

Starting from scratch is, usually, the first approach of most people, there are many reasons for that, like different coding style, something disliked about the use of (classes/functions), to charge more, for not properly assessing of the amount of work, etc, etc.

If you can avoid rewriting everything again, is much better; but implies time to read and understand the code. Obviously, there are some situations when there is no other solution, but you should try to avoid it, for you and for the client. If the other developer used html 4.01 and you want to use html 5, that's not a good reason to scrap, if they used asp and you prefer php, that is not a good reason, unless you can't use that technology, and in that case, you have to tell the client your limitation, of course you may try to argue about quality of one over the other, but don't expect the client to care much about that.

Before accepting a project like that, or before telling the client about delivery time, you have to take your time to read.

Even if the client hates the other developer, they still expect you to do the things fast and finish soon, many times they say that they understand that this is a new project and that time has to start from zero, but inside, they are filing that the clock is ticking, that they started the project time ago and it is still not finish and then, they start putting more pressure on you. So make that point clear.

I would also ask the client about how fast they sent information to the old developer, if they say that it was always on time, I'll start to suspect a bad relation with the client. In my experience, it's uncommon to have materials and answers quick and accurate, so unless I have a more relative answer like "usually on time", "this or that was not clear but we talked about in mails and then ..." things like that, I'd very suspicious.

I'll ask if they still have the proposal from the other developer and will ask what went wrong, I'll try to get all the details.

Basically, you want to get clear if the client is difficult or not. The reason why fired the other developer is something that doesn't affect you, but you can get lot's of information from that fact and should try to use it.

| improve this answer | |

Not the answer you're looking for? Browse other questions tagged or ask your own question.