If your code doesn't do what you want it to do, you have no business optimizing it.

If I lose more sales because of performance issues than I lose because of bugs, or missing (edge) cases,

No, because "does what I want it to" is not the same as "runs perfectly with every conceivable input". I believe the OP chose those words precisely to be vague enough to allow that "good enough" is good enough.

I wonder what makes you think that that's a good thing to say, even if it were accurate.

Ah, you haven't been out of junior class yet.

I wonder what makes you think that that's a good thing to say, even if it were accurate.

He seems to believe it is a "good thing to say" because he's been rewarded handsomely (XP-wise) for trollish behavior on PM.

Other monks appear to think that it is "funny" or "clever".

Great point, JavaFan, (as always...) Of course, if performance is a higher requirement than functionality, then is the function really broken if it meets performance but is suboptimal in its functional scope (aka. fast but got bugs)?

I think the point he's trying to make (and I could be wrong) is that if you optimize a solution prior to getting it fully scoped, you could encounter elements of scope that destroy any work you did in optimizing performance, essentially you're spinning your wheels. Likewise you can introduce unnecessary architectural complexity if you optimize before finishing any functional requirements.

Of course you should never dismiss performance when designing a system...

if performance is a higher requirement than functionality

It's neither a "higher" requirement, nor a "lower" requirement. Performance is always a requirement. In the end, someone or something is waiting for the results, and they aren't going to wait forever. Now, where the balance lies between performance and functionality, that depends on a case-by-case bases. I don't think the blanket statements made by the OP reflect any real world scenarios (which surprise me, as petdance usually comes across as someone with both feet in the business world).

Likewise you can introduce unnecessary architectural complexity if you optimize before finishing any functional requirements.

Or the other way around. ;-) I guess most of us have encountered systems that were beautifully designed, and has implemented every little aspect that was dreamed up before hand, but noone uses it because performance was factored in too late.

If your code doesn't do what you want it to do, you have no business optimizing it.

To give an example, if I use software that calculates an "optimal" route for me to deliver packages to 40 customers, I rather have a slightly optimal route that's ready by the time I start driving, then that I've to wait another few years just to find out I could save a few seconds from my trip.

You've just given a perfect example of why the OP was correct, not a counterargument. In the above example, "what you want the code to do" is to give you a "slightly optimal route" in a reasonable amount of time. Your trade-off is that there might be more optimal routes if you ran the code for longer.

If you're prioritising performance over correctness, then you're seeking an answer that is "good enough" given your time-frame. If your code is doing that, then your code is doing what you want it to. Note that "good enough" is important here. If your code was giving you obviously wrong answers, blindingly fast, you wouldn't be happy. The answers have to at least look correct enough. Ideally you'd have a test suite that flagged your edge cases and bugs, so that when you had time to deal with them you could, even while you made the common cases run well enough and fast enough to keep your business ticking over.

In different fields people would prefer correctness over performance. For example, I'd rather receive my credit card statement a day or two later than usual than have all the numbers added up wrongly. (In this case where Australia Post (the underlying protocol) is slower than the generation and printing of my statement, this is especially true).