Iterative development can go two ways. Either the system goes from strength to strength, with users able to get more features and keep a stable system or the system degenerates and instead of accumulating features it accumulates bugs and bad data until it is no longer used. The latter situation will find people crying out for a “properly” analysed and designed system that they know will have the features that they need.
How do we end up in one situation rather than the other? I think that the key point is whether the system matches the business process that it is supposed to replace. That doesn’t mean that the domain model (http://en.wikipedia.org/wiki/Domain_model) needs to match the business process exactly, but you need to be able to present the users with language and entities that map exactly onto the relevant business objects. Let’s look at a 2×2 matrix to chop the world up
There is a feedback look that operates when we are in the top-box “sweet spot” that constantly drives the improvement of the software in a virtuous circle where the users understand and like the system, even when there are bugs to fix. Likewise there is a “sour spot” that drives the system downwards into chaos as more changes require more bugs that the system is ill-equipped to handle. The quality of its output declines and drags down confidence and interest in the system. In that case, collapse and a re-write are the inevitable conclusion but there may be irrevocable damage to your reputation and the reputation of iterative development.
If you are lucky, you will have a stable problem will be able to make a stable high-quality solution, but most of us aren’t that lucky.
Aside: what do we think of Google docs presentations? It’s not quite powerpoint 2007 but for free and online, really quite impressive.