SNIP
>
>Obviously, that doesn't apply to every application, but in my experience, an astonishing number of running applications are extremely poorly architected and as fragile as a house of cards.

I've been in this business for quite a while now.
My standard approach used to be that if I don't like the way something is architected/written I insist on rewriting (I was a staff manager at the time, not consulting).
Since then I changed my tune 179 degrees (I reserve that one degree for the instances where a rewrite is truly the most sensible) and work with what I've got in front of me, regardless.
For me it was the realization that I was preparing my own excuse for failure... the old is crap anyway and anything I deliver will be provably better than the old crap.

>
>For these apps, we're not talking about burning money, but investing it. It's like the choice of whether to fix an appliance or car one more time or replace it. Keeping it running costs money and aggravation over a period of time; replacing it costs money once. The trick is to find the optimal time for the change.

I don't buy this except in extreme cases. The analogy is not really appropriate because a physical item has a fixed design and has a fixed deliverable. Such things do not have releases or versions that add ever more functionality within its physical constraints for fractions of the original price.
I'd still like to know why any rewrite would necessarily produce a better designed/coded system. Anyone can rewrite a system, even poor designers and programmers. It will end up just like THEY want it, then you might come in the door and see a system too fragile to work on.

cheers


>
>Tamar