Inheriting projects - General Rules? [duplicate]

Question

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?

Answer 1

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.

Answer 2

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.