Software disenchantment

> I have a theory that we're not caring as much about performance and good software because we don't have to, because Moore's Law has led to machines that are fast enough to run our crappy and hastily written code with acceptable performance so the majority of users do not really care about it running more efficient.

I've always said that the lack of performance concerns is not a technology problem, this is a business and a societal problem. Hell, this might just be the first massively-distributed "tragedy of the commons" problem.

tl;dr- companies don't have to directly pay for client-side computing resources, so those companies which offload costs onto the client most efficiently have a competitive advantage. (Also, I kinda veered into talking about mobile computing later on here, and diverged into UX a little bit as well, but IMO performance is absolutely a part of the user experience so it's worth considering the two together.)

If I'm developing a piece of software that's not going to run on software I'm personally paying for, the only degree to which I have to optimize for performance is the point at which performance problems completely outweigh the usefulness of the app's features. You can get away with this for a long time with few repercussions- even longer if you can lock them into the software via "dark features".

The problem is, this leaves little space for companies who want to make highly-performant software, because it's still much easier to sell users on what a product does rather than how it does it... so you often can't afford to optimize for performance, because your competitor is going to gobble up user resources and wow them with shiny new features while you're still "boring" them with the "same-old, same-old". (This isn't how I personally feel, but you see my point.)

In a strange way, it's similar to the problem of designing great UX- the more your user has to use your software, the less you have to worry about making it convenient to use your software. You have successfully externalized the cost of dealing with it to your users.

Web applications themselves are a good example of this- companies with any sort of load absolutely do have to pay a non-trivial cost for each byte coming out of a datacenter or stored in an edge cache. The client's local cache is really the only "free" part of the whole process, so if you can get the client to store your entire app in cache, you can save a ton of actual real-world dollars in CPU cycles (not generating so much HTML/CSS/JS) and networking costs (not transferring so much HTML/CSS/JS) and caching costs (not storing so much HTML/CSS/JS in-house). If you're a startup trying to capture a chunk of a market, and you're only concerned about expanding your customer base, you're absolutely going to do that, whether it's ultimately good for customers or not.

I do think however, there are a couple factors which are changing for the better. First, Moore's Law is slowing down, and a lot of hardware optimizations these days seem to be revolving around getting the same performance using less power, rather than more performance for the same amount of power. Same with storage- application software can't continue bloating forever, we're starting to hit physical limitations.

Secondly, consumers are becoming more technology-literate, and with that literacy, are starting to understand the relationship between performance and features.

Thirdly, OS and device manufacturers are starting to experiment with tightly integrating common services into the system. For instance, NFC payments on mobile, or "iMessage-like" services. This is a bit of a double-edged sword, because OS and device manufacturers are also trying to lock you into their services, but they also have to be more serious about performance and UX because users are interacting with the system much more often than any given app. One way this could dramatically improve is by getting system manufacturers to agree on standards like RCS. When it doesn't make business sense to compete in a space because you literally can't do better than the well-understood solutions, there will be less bloat.

So, to sum it up, I don't think you improve things by getting users specifically to care about performance and efficiency- you do it by attempting to change the calculus around why people and businesses create inefficient software.

> You can format an SSD, download a multi-gig image and install it in under 6 minutes?

5 minutes to download 4 Gb at 100 Mbit/s, 0,5 min to write 4 Gb at 1Gbps

> I'm failing to see the problem with that dialog. It's hardly new.

It’s always been a problem. Trouble is, you want work from both versions combined, not to select one and destroy another

> Everyone thinks that a problem.

Yet new languages (e.g. Rust) are still developed with terribly slow compilers

> It can kill processes (configurable). But AFAIK it doesn't do it randomly.

Well, I meant randomly in a sense that you can hardly predict or control what will happen. Of course it’s a determenistic algorithm, but engineers treat it as a black box.

> Anymore? Really? I reboot my Windows computer one-tenth as often as twenty years ago.

Why do you need to reboot at all?

> 0,5 min to write 4 Gb at 1Gbps

By "install it", I thought you meant install Windows, which takes for longer than 30 seconds. It's not a straight byte copy. For one, part of the install process compiles code for your variation of CPU architecture.

> It’s always been a problem.

In fact, it's less of a problem now than it was 15 years ago. Google Docs, Office 365.

> Yet new languages (e.g. Rust) are still developed with terribly slow compilers

Slow compilers (Rust, TypeScript, Scala, Haskell) almost universally have complex type inference.

Languages with limited type inference (Go, Java) have fast compilers.

It's really a matter of choice of language design, rather than compiler implementation.

> Well, I meant randomly in a sense that you can hardly predict or control what will happen.

This is like complaining search engine results are random because they are complex. Does it really matter?

> Why do you need to reboot at all?

Usually my battery dies.

> By "install it", I thought you meant install Windows, which takes for longer than 30 seconds. It's not a straight byte copy. For one, part of the install process compiles code for your variation of CPU architecture.

That was my point. It does something very slow but unnecessary. If you could install it by straight copy, it would be way faster. And there’re no reasons why it can’t be straight copy (or really fast unzip & compile).

> Google Docs, Office 365

Google Docs disables offline mode by defaults. It only works as long as everyone are almost on the same page. It’s a step forward, yes. I wish using those algorithms was as easy as writing LAMP apps

> Usually my battery dies.

Doesn’t mean it has to reboot. It’s just an implementation design of current OSes. See Phantom OS

I think sometimes we, as programmers, are too worried about our own experience coding than about the final product and its quality. And some of that might have been caused by terrible deadlines imposed by PjMs or "Architechts".