First, the time taken to make it work and get rid of the bugs always expands, compressing any time that might have been scheduled for performance tuning later in the schedule. This makes it much harder to do any kind of optimization late in the cycle. Both of these problems often lead to shipping programs after doing little or no performance optimization. The result is too often code that behaves sluggishly and is frustrating to use. At least a user can report a crash with tangible symptoms, and expect a fixed version of the code.
Users can often avoid buggy features and still get use from the rest of the product.
On the other hand, if the program runs too slowly, or hogs too much memory or disc, they may well have the perception that any problem-report will be ignored. Testing performance early The solution to this problem may be to schedule ongoing performance analysis and tuning time throughout development. Lessons learned from early performance tuning can be applied as later code is written, which may reduce the total time needed for optimization. A principal counter-argument is that the optimizations applied early will tend to obfuscate the functionality of the code, and make it harder to finish and maintain. I find this argument not compelling, because too often performance bottlenecks result from lack of clear organization, and fixing the problem results in clearer code, which is easier to modify and maintain, rather than harder.