I struggle with the same dilemma, to which I also have another one on top. First I'll get to the observations:
Very often developers don't have the faintest clue on how to improve performance.
1.1 Sometimes they ignore computational costs of their implementations.
1.2 They don't know some key performance characteristics of their language (e.g. not knowing how the GIL works in Python)
1.3 They don't know how to make use of a profiler
The costs of a badly performing application are indirect and hard to see.
Projects often run out of funds before optimizing makes sense (as others pointed out).
Sometimes you can just throw more hardware at it top "fix" your problem.
...and that's what is usually done anyway!
So my added dilemma is the following: what's the logic in scaling an inefficient application?
In my experience people that talk about "throwing hardware at the problem" don't consider the future. Having a developer spend a couple of weeks making your code twice as fast might let you get away with five servers instead of ten today, which might save you a few hundred dollars a month. Maybe not really all that great. But when your site has grown and your faster code continues to pay dividends you might be talking about the difference between 500 servers and 1000. Now your investment is paying several developers' salaries.
Of course you never know exactly what parts of your system are going to be critical down the line, what code might be thrown away a couple of years down the line, when (and if) you see that big uptick in traffic, and exactly which optimizations will pay off in the long run. Making those choices is more an art than a science.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I struggle with the same dilemma, to which I also have another one on top. First I'll get to the observations:
Very often developers don't have the faintest clue on how to improve performance.
1.1 Sometimes they ignore computational costs of their implementations.
1.2 They don't know some key performance characteristics of their language (e.g. not knowing how the GIL works in Python)
1.3 They don't know how to make use of a profiler
The costs of a badly performing application are indirect and hard to see.
Projects often run out of funds before optimizing makes sense (as others pointed out).
Sometimes you can just throw more hardware at it top "fix" your problem.
...and that's what is usually done anyway!
So my added dilemma is the following: what's the logic in scaling an inefficient application?
In my experience people that talk about "throwing hardware at the problem" don't consider the future. Having a developer spend a couple of weeks making your code twice as fast might let you get away with five servers instead of ten today, which might save you a few hundred dollars a month. Maybe not really all that great. But when your site has grown and your faster code continues to pay dividends you might be talking about the difference between 500 servers and 1000. Now your investment is paying several developers' salaries.
Of course you never know exactly what parts of your system are going to be critical down the line, what code might be thrown away a couple of years down the line, when (and if) you see that big uptick in traffic, and exactly which optimizations will pay off in the long run. Making those choices is more an art than a science.