Phil Factor (12/18/2008)
When I worked as a technical architect, I would never dream of letting a project go into development unless we had carefully specified the loading (e.g. transactions per second) and the data metrics (e.g. no. of records) that the system had to deal with.
You've obviously worked in companies with very much more static businesses that I have then!
Although, in an ideal world, it would be great to have the numbers for the exact number or records, transactions, queries, etc, in my experience the best you get is usually very rough and likely to change depending on business performance. The best I've usually managed is to get the most up to date estimates and predictions you can, then assume that there going to be off by at least a factor of two. If the system can copy with that, there's a chance the production system wll be OK for a while!
On another point, I would agree with the idea of multiple levels of testing during development. When doing early testing, use small samples of data so you get fast turnaround; once things are beleived to be OK, step up to realistic levels so you can see what it's really going to be like; finally, before release, try it with what you consider ridiculously high levels to see how it's likely to degrade. Chances are
the real world will turn out somewhere between your realistic and ridiculous estimates.
Of course, this also relates to developers always wanting the latest/fastest hardware when they should have some of the oldest/slowest...
If they can produce acceptable performance on that old junk...
Derek