When designing *really* big application, you just cannot be too cautious in design phase. If you hope your code will "evolve" - good luck.

Trying to "evolve" code might work is application where you have knowledge of problem area, so your "feeling" about desig decision will be based on your knowledge and intuition - and yes on your luck.

OTOH, *really* big applications are far too complex to rely on plain intuition and luck. What is worse, there might not be ane person understanding the whole picture. So even XP programming will have setbacks.

Just an example from my experience: I was working recently on a huge project for a big bank. When I started, we were supposed to go live in 2 months. When I left 2 years later, we were 2 months live. And most of the time we were some 2-3 months before going live.

Why? Because bank itself lacked understanding how different deparments collaborate. There were couple of users who know in detail how works department they worked in, couple even had experience in work for more than one dept.

But sometimes part of experience was outdated, or not detailed enough - they knew only about problems for "junior" positions.

Also, big problems have most likely previous solution, which is not adequate, and you need to replace it, but previous solution formed perception of users how solution to their problems should look like. So sometimes you cannot provide better solution, but solution they believe is closer what they used to have. Especially if you are in time constraints as we were, there is not enough time to research and provide better solution - you just go ahead and try to simulate part of what they have without much understanding.

I was added to one obscure part of project, what another (decent programmer, but without design experience) was implementing - to help him. We found that in whole company there was only one person completely understanding this obscure, but very basic and important feature of the system (custom enhancement of big system). He was very helpful, but his time was very valuable and not easy to get.

After much research, we found that database contained various types of wrong data from different stages of implementation of custom part, which he did not want to distract us, and was forced to add features what he needed but decided not to implement in old system, because of expected conversion to new system.

And of course this person was very smart when talking, but completely not capable express himself in writing. So you cannot imagine how bad written specifications were...

It was big struggle.

Summary: In *really big application*, do not expect that there is one person, or even a group of persons, who understands it as a whole, or it will be easy to solicit correct specifications. To overcome this migt be substantial part of problem.

pmas

To make errors is human. But to make million errors per second, you need a computer.