Performance anti patterns

Question

I am currently working for a client who are petrified of changing lousy un-testable and un-maintainable code because of \"performance reasons\". It is clear t

Answer 1

Some developers believe a fast-but-incorrect solution is sometimes preferable to a slow-but-correct one. So they will ignore various boundary conditions or situations that "will never happen" or "won't matter" in production.

This is never a good idea. Solutions always need to be "correct".

You may need to adjust your definition of "correct" depending upon the situation. What is important is that you know/define exactly what you want the result to be for any condition, and that the code gives those results.