Paul G. Allen wrote:
Bad design decision at the start: Wrong language chosen, a proprietary
one, etc. Kinda supports my point.
Firstly, at the time we started, the language we switched to wasn't even
supported on the original target machines. Secondly, the company made
quite a bit of money using the first language that we wouldn't have made
using the second language, due to the quality of the programmers.
Thirdly, the original language wasn't any more proprietary than the
second language - it just wasn't supported on the destination machines.
Fourthly, sure, it's easy to say "well, given what was asked for today,
we definitely should have done something different five years ago."
Unfortunately, it doesn't work that way for me. If it works that way for
you, give me some stock tips.
Once it was to change fundamental
architecture.
The one case that may have nothing to do with language choice.
So? I was asked for examples where projects got rewritten from scratch.
You didn't restrict it to why.
This
happens on occasion, especially when not following a proper SDLC
process.
And, surprise, it often happens when your company goes long enough that
the market changes out from under you. No amount of planning is going to
solve that.
Once we redid it twice because the first was a prototype
grown out of hand and then for performance.
Again, this supports my point: Expect it to be around longer than you
might originally think and do it right the first time.
That was the rewrite. Same language, same infrastructure, etc. And sure,
had I been around when it was done the first time, I'd probably have
done a better job of getting it right.
If you've never done major rewrites of running applications, then you've
never worked for a start up.
I do. All the time. It's a large part of my job. Never re-written
anything that I wrote in the first place.
Ah, well, that's a bit different, now isn't it?
I'm glad you have customers who know what they want when they want it.
Me, I get customers that six weeks into an eight week accounting
software project decide that it should be the customer interacting with
the software instead of the teller.
--
Darren New / San Diego, CA, USA (PST)
His kernel fu is strong.
He studied at the Shao Linux Temple.
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
