Be it resolved that the most effective IT development strategies for systems in which some level of error is considered tolerable depend on having users test prototypes and are best implemented through the "release early, release often" strategy pioneered at UCB for the BSD Unix releases and later honed for the internet age by Linus Torvalds et al.
If your application is the one deciding whether or not to fire missiles at an off course Airbus 380 approaching a nuclear power plant in New Jersey, you probably don't want to test a prototype by releasing it for use. If, on the other hand, your code is intended to connect two internal Domino users whose search terms suggest similar interests, then error is tolerable and releasing your first draft for use will be the quickest way to find out where you went wrong.
On the surface what drives this is the idea that there's a trade-off between the adequacy of design rigor and testing on the one hand and the cost of getting it wrong on the other. In other words, there's an assumption that the cost of failure should correlate with the investment you make in getting the system right the first time: fundamentally that if your code is going to control a power network you'd better be a whole lot more careful about releasing it for early use than if it's going to control an order entry screen.
That argument is perfectly reasonable, but it's less than half the story - and it's the other half that really determines the value of prototyping in business application development.
I've done a number of prototypes -some of which are still in daily production use - and they all have had one thing in common: it's not what you do that fails, it's what you don't know to do.
The reason for that is simple: users will tell you anything you want to know about how they do their jobs, except for how they actually do them - and if you didn't know that they always do whatever it is anyone would know had to be done, well it's because IT management sent them a retard to work with.
I've never built an embedded control program, but I've talked to people who have and those things have something very different in common: operational predictability.
Build software to manage coolant flows in a reactor and everything you need to know about program input and system reactions to change is fully defined. Build something to help stabilise an airplane during landing, and you can be assured that the effects of local airflows experienced in flight are wholly predicted by the equations at hand - and that the pilot won't try to land that airplane upside down.
Business users, of course, will not only assume they can land upside down, but will tell you with perfect honesty that they do this all the time - so you have to make sure the under carriage extends in whichever direction happens to be down at the time of landing.
And that's why prototyping - aka release early and revise often - works so well for business applications: it lets you capture highly variable, and logically unpredictable, user behaviour as it really is, not as they say it is or think it should be.