As a general trend, we’re not getting faster software with more features. We’re getting faster hardware that runs slower software with the same features. […] I would love to see limits reached and explored, utilizing every last bit of performance we can get for something meaningful in a meaningful way.
While mostly a well-argued rant about software development practice, in my reading, “Software disentchantment” – a rather personal account by Nikita Prokopov – indirectly leads to two of the things I see most neglected in current technology development: people and the environment.
As the author points out, some websites today are bigger (in file size) than the entire Window 95 operating system. Even text editors may struggle to use the available power of a top-notch PC to create a fluent typing experience. What is wrong here?
Well, bigger doesn’t imply better. Bigger means someone has lost control. Bigger means we don’t know what’s going on. Bigger means complexity tax, performance tax, reliability tax.
For me, the very same is true beyond the code itself. The same complexity issues escalate to the user level. Beyond the poor user experience of slow-performing software: with ever more third-party dependencies etc., technologies are being created that completely neglect the fact that it is the user’s resources being wasted by building overly complex things: their time (waiting, tweaking, fixing), their money (transferring data, using electricity, having to buy ever more powerful hardware), their dignity (the data transferred to dozens of marketing networks in the background).
And, by the way, our planet’s resources are wasted at the same time: imagine the energy wasted on executing code 10x more complex than needed! Or if a five-year old computer would still be able to smoothly scroll a current website.
Prokopov highlights the need to innovate, even at the price of giving up some of what has been done before:
To have a healthy ecosystem you need to go back and revisit. You need to occasionally throw stuff away and replace it with better stuff.
This, in my opinion, is equally valid for software development as it is for business strategies, design patterns, all kinds of “best practices” etc.
Lastly, the article makes an important point about the responsibility of creators. Is it really reasonable to simply assume users to quietly accept whatever complexity is thrown at them?
[users] are only learned to expect what we can provide. We (engineers) say every Android app takes 350 Mb? Ok, they’ll live with that. We say we can’t give them smooth scrolling? Ok, they’ll live with a phone that stutter. We say “if it doesn’t work, reboot”? They’ll reboot. After all, they have no choice.
This is “design” turned upside down – complete ignorance for the user. Bigger, more complex, poor performance. Wasn’t the main reason we are doing this to solve people’s problems, not create new ones?