Software Disenchantment

Nikita in “Software disenchantment”:

So everything is just a pile of barely working code added on top of previously written barely working code. It keeps growing in size and complexity, diminishing any chance for a change.

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.

See also: “The Sad State Of Web App Deployment” and “Something Slightly Less Terrible”.

---

I think the article is a bit short-sighted, and even wrong on some points: there's a difference between today's software and the one from 10 or 15 years ago — we do have progress. But the overall sentiment is fundamentally correct.

Something is broken, and that's probably because we are still using code to build software.

There's also a slight contradiction when he says we need to delete code, but still need to be able to run things from twenty years ago. If we were more thoughtful with what we build, it could be possible, but to keep a sane and manageable codebase in our current world, we need to accept that we will lose compatibility and devices over time.¹

---

That is not engineering. That’s just lazy programming. Engineering is understanding performance, structure, limits of what you build, deeply. Combining poorly written stuff with more poorly written stuff goes strictly against that. To progress, we need to understand what and why are we doing.

I'm also guilty of that. Look, this website uses Gatsby to generate a few static pages, and this requires 242M of dependencies to build it (not run it, hopefully).

However, the result is extremely fast and satisfying for the user, and the developer experience is top-notch, at the expense of an increase in size of the exported bundle on initial (and uncached) load. Is this a reasonable tradeoff?

---

At the end:

Business won’t care. Neither will users. They 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.

There’s no competition either. Everybody is building the same slow, bloated, unreliable products. Occasional jump forward in quality does bring competitive advantage (iPhone/iOS vs other smartphones, Chrome vs other browsers) and forces everybody to regroup, but not for long.

So it’s our mission as engineers to show the world what’s possible with today’s computers in terms of performance, reliability, quality, usability. If we care, people will learn. And there’s nobody but us to show them that it’s very much possible. If only we care.

On this, I don't completely agree. Yes, in general, people are mostly stuck with what we provide, but users are way too forgiving, and most of the time, don't even see the quality problem² — only a fraction perceives it.³ Even engineers working on products don't necessarily see that something's wrong. How many engineers don't care about design, visual consistency, coherence, and speed, for example?⁴ How many don't see that their users are struggling?

But there's a choice to be made by users: choose carefully, invest and learn, accept to spend a bit more on something better and more durable, change less often, and don't restrict yourself to the most ugly and cheap solution all the time, just because that was the first and easy choice.