The world could run on older hardware if software optimization was a priority

> the market sells as if all goods were high-quality

The phrase "high-quality" is doing work here. The implication I'm reading is that poor performance = low quality. However, the applications people are mentioning in this comment section as low performance (Teams, Slack, Jira, etc) all have competitors with much better performance. But if I ask a person to pick between Slack and, say, a a fast IRC client like Weechat... what do you think the average person is going to consider low-quality? It's the one with a terminal-style UI, no video chat, no webhook integrations, and no custom avatars or emojis.

Performance is a feature like everything else. Sometimes, it's a really important feature; the dominance of Internet Explorer was destroyed by Chrome largely because it was so much faster than IE when it was released, and Python devs are quickly migrating to uv/ruff due to the performance improvement. But when you start getting into the territory of "it takes Slack 5 seconds to start up instead of 10ms", you're getting into the realm where very few people care.

That's true. I meant it in a broader sense. Quality = {speed, function, lack of bugs, ergonomics, ... }.

You are comparing applications with wildly different features and UI. That's neither an argument for nor against performance as an important quality metric.

How fast you can compile, start and execute some particular code matters. The experience of using a program that performs well if you use it daily matters.

Performance is not just a quantitative issue. It leaks into everything, from architecture to delivery to user experience. Bad performance has expensive secondary effects, because we introduce complexity to patch over it like horizontal scaling, caching or eventual consistency. It limits our ability to make things immediately responsive and reliable at the same time.

> You are comparing applications with wildly different features and UI. That's neither an argument for nor against performance as an important quality metric.

I never said performance wasn't an important quality metric, just that it's not the only quality metric. If a slow program has the features I need and a fast program doesn't, the slow program is going to be "higher quality" in my mind.

> How fast you can compile, start and execute some particular code matters. The experience of using a program that performs well if you use it daily matters.

Like any other feature, whether or not performance is important depends on the user and context. Chrome being faster than IE8 at general browsing (rendering pages, opening tabs) was very noticeable. uv/ruff being faster than pip/poetry is important because of how the tools integrate into performance-sensitive development workflows. Does Slack taking 5-10 seconds to load on startup matter? -- to me not really, because I have it come up on boot and forget about it until my next system update forced reboot. Do I use LibreOffice or Word and Excel, even though LibreOffice is faster? -- I use Word/Excel because I've run into annoying compatibility issues enough times with LO to not bother. LibreOffice could reduce their startup and file load times to 10 picoseconds and I would still use MS Office, because I just want my damn documents to keep the same formatting my colleagues using MS Office set on their Windows computers.

Now of course I would love the best of all worlds; programs to be fast and have all the functionality I want! In reality, though, companies can't afford to build every feature, performance included, and need to pick and choose what's important.

> You are comparing applications with wildly different features and UI. That's neither an argument for nor against performance as an important quality metric.

Disagree, the main reason so many apps are using "slow" languages/frameworks is precisely that it allows them to develop way more features way quicker than more efficient and harder languages/frameworks.

> If a slow program has the features I need and a fast program doesn't, the slow program is going to be "higher quality" in my mind.

That’s irrelevant here, the fully featured product can also be fast. The overwhelming majority of software is slow because the company simply doesn’t care about efficiency. Google actively penalized slow websites and many companies still didn’t make it a priority.

> That’s irrelevant here, the fully featured product can also be fast.

So why is it so rarely the case? If it's so simple, why hasn't anyone recognized that Teams, Zoom, etc are all bloated and slow and made a hyper-optimized, feature-complete competitor, dominating the market?

Software costs money to build, and performance optimization doesn't come for free.

> The overwhelming majority of software is slow because the company simply doesn’t care about efficiency.

Don't care about efficiency at all, or don't consider it as important as other features and functionality?

Not being free upfront isn’t the same thing as expensive.

Zoom’s got 7,412 employees a small team of say 7 employees could make a noticeable difference here and the investment wouldn’t disappear, it would help drive further profits.

> Don't care about efficiency at all

Doesn’t care beyond basic functionality. Obviously they care if something takes an hour to load, but rarely do you see considerations for people running on lower hardware than the kind of machines you see at a major software company etc.

If you're being honest, compare Slack and Teams not with weechat, but with Telegram. Its desktop client (along with other clients) is written by an actually competent team that cares about performance, and it shows. They have enough money to produce a native client written in C++ that has fantastic performance and is high quality overall, but these software behemoths with budgets higher than most countries' GDP somehow never do.

> Zoom’s got 7,412 employees a small team of say 7 employees could make a noticeable difference here

What would those 7 engineers specifically be working on? How did you pick 7? What part of the infrastructure would they be working on, and what kind of performance gains, in which part of the system, would be the result of their work?

What consumers care about is the customer facing aspects of the business. As such you’d benchmark Zoom on various clients/plugins (Windows, Max, Android, iOS) and create a never ending priority list of issues weighted by marketshare.

7 people was roughly chosen to be able to cover the relevant skills while also being a tiny fraction of the workforce. Such efforts run into diminishing returns, but the company is going to keep creating low hanging fruit.

This; "quality" is such an unclear term here.

In an efficient market people buy things based on a value which in the case of software, is derived from overall fitness for use. "Quality" as a raw performance metric or a bug count metric aren't relevant; the criteria is "how much money does using this product make or save me versus its competition or not using it."

In some cases there's a Market of Lemons / contract / scam / lack of market transparency issue (ie - companies selling defective software with arbitrary lock-ins and long contracts), but overall the slower or more "defective" software is often more fit for purpose than that provided by the competition. If you _must_ have a feature that only a slow piece of software provides, it's still a better deal to acquire that software than to not. Likewise, if software is "janky" and contains minor bugs that don't affect the end results it provides, it will outcompete an alternative which can't produce the same results.

> Software costs money to build, and performance optimization doesn't come for free.

Neither do caching, operational/architectural overhead, slow builds and all the hoops we jump through in order to satisfy stylistic choices. All of this stuff introduces complexity and often demands specialized expertise on top.

And it's typically not about optimization, but about not doing things that you don't necessarily have to do. A little bit of frugality goes a long way. Often leading to simpler code and fewer dependencies.

The hardware people are (actually) optimizing, trying hard to make computers fast, to a degree that it introduces vulnerabilities (like the apple CPU cache prefetching memory from arrays of pointers, which opened it up for timing attacks, or the branch prediction vulnerability on intel chips). Meanwhile we software people are piling more and more stuff into programs that aren't needed, from software patterns/paradigms to unnecessary dependencies etc.

There's also the issue of programs feeling entitled to resources. When I'm running a video game or a data migration, I obviously want to give it as many resources as possible. But it shouldn't be necessary to provide gigabytes of memory for utility programs and operative applications.