A Missed

Why does it feel like the devices we use are getting slower over time? A smartphone I bought a few years ago seems to be losing its edge when browsing websites. My computer struggles to play audio. Even my car’s interface can’t keep up anymore after all the updates. Am I just imagining or were they always like this?

No, these devices aren’t actually getting slower, it’s the software that is getting more bloated. Whenever new hardware is released out in the wild, it takes only a few months until it becomes the benchmark for software developers. Because hell, why not. We have all these resources to utilize, why wouldn’t we. Why give a fuck about the needs of users.

If you’ve observed this too, it’s not just your imagination. Software is becoming increasingly complex and requires more resources than ever before. As CPU power increases, software is expanded to consume that extra performance. We live in the era of disposability.

Fabien Sanglard recently wrote a fantastic article on this subject which triggered me to share his thoughts here. Fabien writes:

For a few months, those who will buy M1 machines will enjoy great responsiveness and blazing start-up time. Some once bloated applications will again behave like most tools should. But soon these metrics will start to degrade. Responsiveness and start-up time will progressively revert to what they used to be and old ‘non-M1’ machines will become even slower than they used to.”

Fabien then continues:

Doing the same thing should never become slower. Starting up an application should never take longer than it used to. If a feature is going to cost start-up time, I would rather not have it. Is it that we don't care about start-up time? Or is it that we don't have the choice?”

And I think there’s wisdom in Fabien’s words. As an industry, we aren’t paying attention. We don’t care, or we don’t have the choice. Either way, we forget the user, the performance, and that there’s more hardware than ours, and that not every­one on this planet has the latest and greatest devices or the connection speeds that we, ourself, might have. I wrote about this in 2015, but the situation is now even worse.

Fabien also shares ideas from Brett Wilson, a Software Engineer in the Chrome team. The principle their team follows is:

We carefully monitor startup performance using an automated test that runs for almost every change to the code. This test was created very early in the project, when Google Chrome did almost nothing, and we have always followed a very simple rule: this test can never get any slower. Because it’s much easier to address performance problems as they are created than fixing them later, we are quick to fix or revert any regressions. As a result, our very large application starts as fast today as the very lightweight application we started out with.”

And I think more teams should do this. Don’t just trust your gut feeling. Maybe there isn’t much a single person can do on a large scale, but by putting my thoughts onto this post I am at least sharing this forward and making sure we’re implementing this practise with all my clients. ❦