The key is that hardware has marketpreassure to become faster and faster. Software gets faster if there is market preassure (see gaming & financial). When the feature backlog is more important than performance that is obviously what is prioritized. You obviously can't work on everything.

The feature backlog is rarely more important than performance but you often see it being pushed ahead of nonfunctional concerns for presentational reasons.

I am actually interested in your context. Usually the return on investment analysis favors features over performance especially in a B2B environment.

"Blah blah blah Return on Investment, B2B I'm a 90s business speaker. Hi!"

- If your product does not work it does not work, regardless of what you have in your requirements.

That’s... something.

For the most part users or companies buy features, not performance. You can have the fastest software ever but if it doesn’t have the features I actually need to use it then, sorry, no dice.

If performance is one of your features then fair enough, but it’s not for a lot of software.

> not performance

This is NOT true. There is almost always an expectation that your application have a reasonable performance profile. It's often not a captured requirement, but I guarantee you once things slow to a crawl you WILL get an escalation.

Do you know what happens when escalations become too frequent? Progress grinds to a halt as developers have to churn out of what they're doing to address non-functional issues.

Somebody operating at a product owner level rarely has any concept of this stuff. It's up to the engineering team to be the bad guy and tell him or her that they're not going to get their laundry list satisfied in the time that's available and actually deliver usable software.

The problem with your statement is that it was unbounded. What you are saying is “when your performance is bad, features should take a back seat”. That i agree with.

But “reasonable performance” is relative and context dependent

No, I was presenting my experience that when given a choice of features over “quality” (however you choose to quantify it) we almost always see a push for the former. Unless of course you have a robust communications arrangement with your techies.

That's a quite unobvious consequence of the software progress. Making software be "a bunch of bricks for creating applications" do come with costs. And the main cost is performance.

Where do you get 1% from? We're several orders of magnitude further than that from the Landauer limit, if that's what you're referring to.

However, there is considerable economic incentive to keep Koomey's law going - mostly from mobile these days, since increased computations per joule means longer battery life.

Less than 1%, I'd say is a super optimistic bid, I couldn't remember what it was called (Landauer's principle) but knew it was less than 1%

if that's a business priority, that's a business priority. But it's not up to developers to set those.

Do you think the market is not pricing it correctly?

In the dawn of computing, machines were far less common, much more expensive, and society was willing to pay programmers boatloads of money to write optimized code because that was cheaper.

The hardware engineers did an excellent job, they reduced costs of computing by a lot. Society is not willing to pay programmers boatloads of money to write optimized code; because hardware is cheap, they can do fine without that optimization.

Whether we thing the pricing is correct or not is a different question I guess. We could theoretically raise computing prices artificially (say through taxation).

... or reduce software engineering salaries. Arguably, people want faster software if they also want faster hardware.

Well, consider Slack as an example.

Performance-wise, it's bottom of the barrel quality. A single developer has done, in this compartment (Ripcord), much better than their team did. If we want to consider similar languages, Microsoft did enormously better with VSC.

The result is, sadly, that Slack is still widely used.