>Ok, lets put it this way, in the development cycle, the overall speed of the application isn't the decideding factor on what features are included, and what aren't.

That I can understand & agree with.

>Therefore, if the app doesn't run as fast as it can, thats a good thing, since it will be able to perform very well on tomarrows hard ware.

This is where you lose me - why is it a "good thing". How do you know how it will perform on something that isn't in existence yet ? I seem to remember there was an issue with various Microsoft code optimisations in VC++ defeating some of Intels caching optimisations on faster chips (I can't remember which ones) - which had the effect of making the software run slower on faster hardware. The fact that it doesn't run as fast as it can may indicate some underlying problem, like too many features - are you trying to pack too much in, if it dosn't appear to perform well today, that could affect you sales today & in two years time when the hardware is up to the job, the customers memory will remain, so again maybe not a "good thing".

I can understand that slow may not necessarily be a bad thing, but it can never be a good thing.

>That does NOT mean the users will not be able to use the app at a suitable speed, like you say.

It was you who said that slow was good, if you think slow is suitable, then that's where we differ. As Dragan said though, it's a balancing act of what you want to achieve, and IMO, software produced today should have a better than adequate/suitable performance on the typical hardware that is in use today. From my POV, writing bespoke s/w, I usually do not have the luxury of being able to produce s/w that is 2 years ahead of the hardware required to run fast, the client wants it now & wants it to run better & faster on the same machines.