>>>Sometimes the best choice is to throw everything away and start over.
>>
>>It's often my preferred method once I lock onto the idea the original guy didn't have a good design. It's just faster. Writing code doesn't really take very long once you know what it is you need to accomplish.
>
>That is 100% right. Provided that you are after real solution.
>
>Problem is that some times temporary consultants (or even entire inhouse dev teams) are more interested in max# number of (vaguely justifiable) billing hours (or prolonging their project/contracts) then solving problem that they are brought/paid to resolve at first place. If you have company unfortunate enough to depend on these kind of ______, then bad code is keep on piling up on top of each other into massive piles of garbage, until it all become complete madness.
>
>After it all fall apart, there comes someone with your approach who finally decide to cut the cr*pp and do full rewrite.
>However not long after you are gone, there comes someone fresh off the latest tech convention, who find that your system/code is good, but not done according to the best coding practices (or latest technology) and thus in need of some major refactoring...
>
>And there we go again. Never ending cycle of exciting technology innovation... :))

These are all very good points.

I do agree with Nick in that I've found most of the time it is not because of a consultant trying to inflate his hours, but most because the consultant did not know how to do proper analysis to define the problem to be solved in the first place or didn't realize how deep the problem was or because he did not have sufficient reputation or people skills to convince management of what was really needed or the best approach to take.

I've been lucky in that usually when I get brought in on project rescue it is because they asked for me and most of the time they will even listen if I tell them just how bad it is. Of course, to make that work you have to be able to deliver very quickly on something that *does* work, so I'm pretty careful about telling them to throw it all out and start over. Careful, but never reluctant.

Unfortunately, many in our "profession" and most of those who hire us, think that what we do is write code. That is also the reason they think outsourcing to someplace where they write code cheaper is an option.

I like to think what I get paid to do is solve problems, and to as I've often said, the people who pay me don't care if I do that with code or voodoo dolls as long as it gets done and it works and it even solves problems they didn't know they had yet.

But that usually involves a lot of "client wrangling" and being able to convince, scare, flatter, browbeat, cajole or ignore the right people at the right time.

I think too often consultants neglect developing big-picture business/domain analysis skills and the ability to be persuasive to management that the analysis is correct.

That said, there are always situations where a lot of factors restrict your options in how to solve the problem or how much refactoring you are allowed to do. And there are always decisions to make about the trade-offs involved in doing it there way or not doing it.

Golden Rule is : client's gold, client's rules.

It is a very good argument for trying to develop a consulting practice that is based pretty much on referral so at least you are going in with the benefit of the doubt that your advice may be worth as much as your coding skills.

But the Hentzen rule states : better to lose a client and be sorry than to take a client and be sorry :-)