>>http://www.infoworld.com/articles/tc/xml/01/10/29/011029tcwinxp.xml
>>
>>And thats a surprise? Sometimes people don't understand innovation. I write shrink wrapped software, and we WANT it to be slow. Why? Because we know that in two years the hardware will be able to run it fast, and we'll have faith in our feature set.
>
>So the purchasers of your product have to put up with something that can only run slowly for 2 years before they can buy the required hardware to get it to run at a suitable speed ? I guess when the hardware is up to speed, you release another version which runs slowly again, because in two years more the hardware will be able to cope again.
>
>What benefit is there to your company to force the user into upgrading their hardware ?
>
>I have often thought that there is a different mindset between those writing shrinkwrapped s/w & those writing bespoke s/w. The former tend to write for their own benefit with little thought for the customer (as evidenced by the attitude that if it doesn't run fast enough, let them upgrade their hardware), losing 1 or 2 customers doesn't really matter to them. The latter are customer focused, the total cost to the customer is important, providing a system that will only operate at an acceptable speed in two years time is not an option.
>
>When I buy a new product, I want it fast NOW, if in 2 years time I upgrade & it's blindingly fast, that's a benefit. If I know it's not going to be fast now, then I'll wait 2 years or more until I upgrade & then I'll buy.

Additionally, if you're writing software which will be fast on future machines, you're fighting the products which are fast today. Your sales pitch may be the features that the other products don't have, but then you may lose if these features aren't important to the customer.

IMO, this is something you have to balance. If the "suboptimal" (quotes come from the original Microsoft's sentence "if your machine is suboptimal, you may want to upgrade the hardware") speed comes from features which are crucial for the competitive edge your product has, OK; but if it is caused by something which is not so important... rethink it.

My rule of thumb is
1. to develop on a machine which is not the fastest. If I perceive the performance as at least decent, I can always demo it as blazingly fast on a state-of-the-art machine, and the performance on the end user's machine won't be too bad either.
2. confess my sins to coverage profiler

OK, I'm all thumbs... but I'd never say I WANT my app to be slow. I may say only as much as "this part may be a little slow on this machine, but...".

I've had customers who had machines way beyond obsolete age, and they were still sort of satisfied... and once they upgraded they were amazed with the speed. But they had decent performance in the beginning as well.