>I hear you, but hopefully you'll admit as well that certain things not always under the control of the developer.
I'll definitively agree that "forces beyond the single app" are determining the speed as well.
[there were once a couple of thousand machines set to defrag at 12:00 each day by way of "golden disk" <bg>] I'll also agree that some of the efforts to speed up apps are not *really* cost effective, and if *perceived* speed is important I'll add progress bars, even if this will make the operation take ever so slightly longer.

>Some mornings Outlook loads faster than others. Once in a while, Outlook and Word seem to crawl...and then the next morning it's fine again. As a test, I did three consecutive cold boots on my older Pentium and loaded his program - and each time the first load varied in time by as much >as three seconds.

But I try to control as much of this as possible. How often have you seen totally botched up installs ? If they are done across hundereds of machines [all in the name of security and cost effective working of administration] this can cost more than any effort to speed up the "single app". One of my rules of operation is: Any [more] information I have can only hurt me if I use it in a dumb way <bg>.

>Some users would care greatly about that - and others are thinking about other things and may >never notice, or notice but don't place a big weight on it.
>
>A variety of factors and practices lead to satisfied customers, speed certainly being one of them.
Fully agree: sometimes even "slow" ways of doing things [mining the net via IE-spiders for instance] can satisfy the customer, if the speed envelope and/or cost for speedier ways of reaching the same result are discussed up front.

Regards

thomas