[dahfizz]

It sounds like you just don't include performance in your acceptance criteria. You're using a lot of words to basically say that you don't care about performance.

I don't find it acceptable to merge something that I know could be 10X faster with a bit more work. Part of my acceptance criteria is "has reasonable performance".

Performance optimization is contentious because everyone has to draw the line somewhere. You can sink an almost unlimited amount of time making a complex program faster. But I've seen so many devs just ignore it altogether, where half a day of work literally makes the thing they made 10x faster.

[jerDev]

I feel more work than is necessary is always a waste.

Unless there is a business requirement for something to be 10x faster, and that is rooted in $’s, there is no reason to be more than 1x.

Performance criteria should only be measured by whether or not you lose money/customers from it.

It’s not an EM’s job to have performance criteria themselves. That should be dictated by business needs

[Delk]

> Performance criteria should only be measured by whether or not you lose money/customers from it.

While I agree that performance optimization for no tangible benefit isn't generally useful, I find it quite cynical to think of the loss of customers as the only measure that could or should matter.

If a product's user experience is measurably or subjectively worse, but not enough to drive people away, it's still a worse experience.

That may or may not matter to the owners of the company, and of course putting too much effort into details that don't affect the business should be avoided. It's also a reasonable view that one needn't do better than is necessary for the bottom line.

Some people like to take pride in building good products, though, and care about the experiences of their users. It sounds rather cynical to think that one should refrain from ever making anything better, or that it's somehow wrong to care about users' experience, if it isn't enough to immediately affect the bottom line.

(Also, perceived quality could affect user opinions in the long run and, when compounded with other things, could also affect the bottom line even if the effects aren't immediate. Trying to build products of high perceived quality may be a reasonable strategy, and a part of that might be to use good quality, possibly including performance, as a heuristic. But that's a bit of a different matter.)

[palata]

My problem with that argument is that the business requirement is based on what we can convince the user to buy. Users won't pay more for a better product if they don't understand it's better.

And one may say that "if they don't make the difference, then the bad products are fine after all", but I think that's shortsighted. By continuously favouring the worse but cheaper design, it has brought the industry where it is today: "better write bullshit that ships now than a good product that users won't buy anyway, because they bought the bullshit from the competitor already".

[anonymoushn]

commonly the cost is externalized to millions of people who spend hours waiting on the thing.

[ElFitz]

See https://www.folklore.org/StoryView.py?project=Macintosh&stor...

[ehaliewicz2]

And in turn, instead of doing extra work once, you are making every computer that runs your software do extra work every time.

[ratww]

And every user that runs their software is also probably a bit less productive than they could be, since they have to wait around.