[pantaloony]

Seriously. This whole part of the comment tree has been fabulously enlightening. Great insight into the psychology of how we end up with chat clients that do less with 20x the resources than entire operating system + office suites of yesteryear.

[aprdm]

I feel you tried to be snarky and I didn't really follow even what you tried to imply! Regardless would like to have your opinion if you don't mind explaining it better.

[pantaloony]

I’d figured it was mostly cheap companies driving the broadly terrible performance of modern software for often fairly small benefits to speed and dev cost, but it turns out there’s a much stronger contingent of software developers with not just a tolerance for business-driven trade-offs, but a strongly enabling attitude toward the whole thing, apparently not seeing what they’re doing the same way I do at all. Adding this information, observed software quality makes a lot more sense to me now.

[_____s]

I'm not sure it's the cheap companies or developers driving this. Even companies that pay really well produce pretty slow software (Gmail, etc.). It's mostly the ecosystem in which software is developed.

As someone else said, businesses hire software engineers to solve business problems. Speed often isn't a priority. Fast software will make the experience perceivably better, but it's hard to get on a sales call and tell a potential customer that your application loads much faster when they are looking for feature X. And most companies buying software are looking at a checklist of features first and then maybe the experience.

You also need to put in the time to make software fast and then keep it fast. It's not something you can tack on at the end—if you want something to be fast, that has to be carefully considered from the very beginning. By the time people notice something is too slow, you're burdened by half baked architecture and a monstrosity of a codebase. At that point, it's near impossible to really make anything fast.

[gregjor]

> most companies buying software are looking at a checklist of features first and then maybe the experience.

I think the hugely successful SalesForce proves this point. Just one standout among many such products.

[bananaface]

I would argue they won because of marketing, not because they had unique functionality. Features are not that hard to build, most basic tooling can be cloned with a relatively small budget.

[_____s]

Most enterprise businesses win because of better sales and distribution, but your product ultimately has to support your sales. Salesforce had both (and other advantages). How does sales work in medium to large B2B? You'll get a RFP with a list of questions, you'll often get a list of features that company X wants. Naturally, as a company, you'd focus on building those features instead of optimising speed.

If the market values fast software, you'll see a lot more fast software. There _is_ a lot of unnecessarily slow software these days, so it _is_ starting to happen. Think Superhuman, Linear.app, etc. — an entire category of software based primarily on the idea of being fast, aimed at the power user. If these apps succeed, you'll see a lot more of them. If the market doesn't value fast software, most commercial software will be slow.

[gregjor]

SalesForce ticks enough checkboxes. Competing products may tick the boxes too, but without great marketing that won’t matter, the company that can sell their product will win.

My point was that SalesForce has fairly poor user experience and performance, but does offer the features. It has the additional advantage (for SalesForce) or quick lock-in once the customer commits to it. SalesForce has improved the user experience over time because they have the customer base and revenue to allow that.

[aprdm]

Software developers are hired by business to solve business problems.

Optimization of speed is sometimes it, sometimes it isn't.

I have worked accelerating algorithms in VHDL with a PCI-e interface, embedded linux without a MMU because a MMU uses too many logical gates, digital signal processing systems (FFT, goertzel, sigma delta filters) that had to process a lot of data under uS and etc.

Now a days I work more in the devops space, full stack dev and whatnot. I have worked with a lot of technologies, different constraints, different teams, different companies (12 in total) in different industries.

Trying to paint all business and developers as bad or as cheap because business requirements do not align with your view isn't really fair.

[bananaface]

Twitter failing to load on a stable connection and crashing the browser if you scroll too far is not the result of business tradeoffs. It's a failure to achieve their own goals.

[aprdm]

Are you sure there's not something wrong with your environment? Twitter has lots of users (me included) and is not a problem I have seen in any platform I access twitter from.

[pantaloony]

I also hit errors following links to twitter more often than not, reliably, on all sorts of environments. It feels like they’re doing some kind of cache-related routing based on headers. Often “refresh” doesn’t fix it, but hitting enter in the address bar does. Seen on iOS, macOS, Windows, and Linux, mostly in very normal browsers (I’d expect mobile Safari in particular is at least on their top-5 most-seen browsers). I’d assumed they were trying to annoy me enough that I install their app. I’ve seen many others report the same kind of reliable, very frequent errors.

Notably, I’m also not logged in, which might be another thing they’re trying to get me to do and another difference between those who hit this more often than not, and those who rarely or never see it. It’s been like this for years.

[pantaloony]

> Trying to paint all business and developers as bad or as cheap because business requirements do not align with your view isn't really fair.

Yes, that would be unfair.