Well, yes, but too often "soft" requirements get lost, like performance or the ability to be supported by anyone who wasn't the author. I'm not IN support, but I've been there and man I feel for those guys. Getting crap dumped on them that has no documentation, architectural designs that were pulled from someones backside in the heat of the moment of getting it done quickly, inconsistent standards being applied, wheel reinvention, etc.

On the bright site, budgets for support are much higher, because application is in production and generates real money. So even though it's hard to support messy code, there is no risk that all these efforts will be wasted on something useless.

Prototype is really a dirty word in programming, but there's no reason you can't produce a small, well written app which does some of what's needed and build from there.

As opposed to a crappily written ball of mud which does most of what's needed, but poorly.

> but there's no reason you can't produce a small, well written app which does some of what's needed and build from there.

Depends on where you work, I guess. Part of my personal hell right now is our architecture (which was written "elsewhere" and is given to us from on high) prevents such luxuries. It's an all-in affair, and deviation is met with retribution. Unit testing is nigh impossible with it, so I try to unit test the best I can of MY stuff that gloms onto its bulbous, massive exterior.

I agree with your point; don't get me wrong; but sometimes there are external forces at play that make the "right way to develop" hard to impossible.

The 'right' answer there is to system test first (eg. set up a dev system and run things like selenium against it) and then you can start to pull stuff out into libraries and unit test it.

The standard way around the 'luxury' attitude is to start with fixing downtime, and grow from there.