Bad argument up for scrutiny here. There are many different kinds of invalid arguments and it’s a great asset to be able to detect them quickly.
Here’s a fictive situation, developers and the person they report to – the project leader.
A: This code will render a very high number of database calls and will be slow. It will also cause so much load that the system will crash with a not so high number of simultaneous users.
B: You are talking about optimization. Premature optimization is the root of all evil in our business. Let’s just go ahead and optimize when needed.
The project leader thinking – “Good lord, in my team there is a person doing premature optimization which is the root of all evil”.
Many interesting things going on here. First of all, what A wants to do is to avoid doing something that is highly inefficient and has caused disastrous consequences before. To call this optimization is misleading at best, it is in fact plain mis-attribution.
Secondly, saying that premature optimization is the root of all evil in this situation is a simple but efficient suppression technique.
A is clearly in a difficult position. Although his position is sound, he appears to be a danger to the project.
To put things differently: If you know now that the inefficient code will have too poor results it’s just common sense to make it more efficient.
To spend a lot of effort making code more efficient than you know will be required is premature optimization.
This is very basic, but the argument can be heard nevertheless.