Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- The article is kind of right about legitimate bloat, but "premature optimization is evil" has become an excuse to stop thinking about efficiency entirely. When we choose Electron for a simple app or pull in 200 dependencies for basic tasks, we're not being pragmatic, we're creating complexity debt that often takes more time to debug than writing leaner code would have. But somehow here we are, so...by SurceBeats
- Tangent, but software bloat always leaves me wondering what hardware/software could be if we had different engineering goals.
If we worked hard to keep OS requirements to a minimum- could we be looking at unimaginably improved battery life? Hyper reliable technology that lasts many years? Significantly more affordable hardware?
We know that software bloat wastes RAM and CPU, but we can't know what alternatives we could have if he hadn't spent our metaphorical budget on bloat already.
by benrutter - TFA lists maintainability as a benefit of bloat ("modularity, extensibility, code patterns make it easier to maintain"). Completely ignores how bloat harms maintainability by making code unknowable.
Stack enough layers - framework on library on abstraction on dependency - and nobody understands what the system does anymore. Can't hold it in your head. Debugging becomes archaeology through 17 layers of indirection. Features work. Nobody knows why. Nobody dares touch them.
TFA touches this when discussing complexity ("people don't understand how the entire system works"). But treats it as a separate issue. It's not. Bloat creates unknowable systems. Unknowable systems are unmaintainable by definition.
The "developer time is more valuable than CPU cycles" argument falls apart here. You're not saving time. You're moving the cost. The hours you "saved" pulling in that framework? You pay them back with interest every time someone debugs a problem spanning six layers of abstraction they don't understand
- Back in the good old days, I used to play Quake 1 multiplayer (QuakeWorld) a lot on Internet servers. You could place an "autoexec.cfg" file in Quake folder, that automatically executed commands after launching the game, including /connect [IP Address]
The time needed from the moment you launched the game (clicked on the .exe) to the moment you entered the server (to the map view) with all assets 100% loaded was about 1 second. Literally! You click the icon on your desktop and BAM! you're already on the server and you can start shooting. But that was written by John Carmack in C :-)
From other examples - I have a "ModRetro Chromatic" at home which is simply an FPGA version of the Nintendo Game Boy. On this device, you don't see the falling "Nintendo" text with the iconic sound known from normal Game Boys. When I insert a cartridge and flip the Power switch, I'm in the game INSTANTLY. There's simply absolute zero delay here. You turn it on and you're in the game, literally just like with that Quake.
For comparison - I also have a Steam Deck, whose boot time is so long that I sometimes finish my business on the toilet before it even starts up. The difference is simply colossal between what I remember from the old days and what we have today. On old Windows 2000, everything seemed lighter than on modern machines. I really miss that.
by _dcez - The question is of course always where someone draws the line, and thats part of the problem.
Too many people have the "Premature optimization is the root of all evil" quote internalized to a degree they won't even think about any criticisms or suggestions.
And while they might be right concerning small stuff, this often piles up and in the end, because you choose several times not to optimize, your technology choices and architecture decisions add up to a bloated mess anyway that can't be salvaged.
Like, when you choose a web framework for a desktop app, install size, memory footprint, slower performance etc. might not matter looked at individually, but in the end it all might easily add up and your solution might just suck without much benefit to you. Pragmatism seems to be the hardest to learn for most developers and so many solutions get blown out of proportion instantly.
by Grumbledour - > There are still highly demanded optimized programs or parts of such programs which won't disappear any time soon. Here is a small fraction of such software: > ... > Such software will always exist, it just moved to some niche or became a lower level "backbone" of other higher level software.
Yes. I’ve been working for years on building a GPU-based scientific visualization library entirely in C, [1] carefully minimizing heap allocations, optimizing tight loops and data structures, shaving off bytes of memory and microseconds of runtime wherever possible. Meanwhile, everyone else seems content with Electron-style bloat weighing hundreds of megabytes, with multi-second lags and 5-FPS interfaces. Sometimes I wonder if I’m just a relic from another era. But comments like this remind me that I’m simply working in a niche where these optimizations still matter.
by rossant - The "development time is more important than performance" motto treats bad performance as the problem with software, when in reality poor performance is a symptom of growing software complexity. I'm sure that each individual coder who has contributed to software bloat believed that their addition was reasonable. I'm sure everyone who has advocated for microservices fully believes they are solving a real-world problem. The issue is that we don't treat complexity as a problem in-and-of-itself.
In physical disciplines, like mechanical engineering, civil engineering, or even industrial design, there is a natural push towards simplicity. Each new revision is slimmer & more unified–more beautiful because it gets closer to being a perfect object that does exactly what it needs to do, and nothing extra. But in software, possibly because it's difficult to see into a computer, we don't have the drive for simplicity. Each new LLVM binary is bigger than the last, each new HTML spec longer, each new JavaScript framework more abstract, each new Windows revision more bloated.
The result is that it's hard to do basic things. It's hard to draw to the screen manually because the graphics standards have grown so complicated & splintered. So you build a web app, but it's hard to do that from scratch because the pure JS DOM APIs aren't designed for app design. So you adopt a framework, which itself is buried under years of cruft and legacy decisions. This is the situation in many areas of computer science–abstractions on top of abstractions and within abstractions, like some complexity fractal from hell. Yes, each layer fixes a problem. But all together, they create a new problem. Some software bloat is OK, but all software bloat is bad.
Security, accessibility, and robustness are great goals, but if we want to build great software, we can't just tack these features on. We need to solve the difficult problem of fitting in these requirements without making the software much more complex. As engineers, we need to build a culture around being disciplined about simplicity. As humans, we need to support engineering efforts that aren't bogged down by corporate politics.
by aaaashley - No software bloat isn't ok. Tech debt can be ok, and software bloat can be the consequence of tech debt taken on with eyes open. But to say that (some) software bloat without considerations is ok is how we have the fastest machines imaginable and still end up with UI that can't keep up visually with keystrokes.
Quoting Knuth without the entire context is also contributing to bloat.
> Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered.
> We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.
by karmakaze