←back to thread

Some software bloat is OK

(waspdev.com)
50 points senfiaj | 1 comments | 04 Nov 25 08:27 UTC | HN request time: 0s | source
Show context
adamzwasserman ◴[04 Nov 25 14:51 UTC] No.45811656[source]▶
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

replies(3): >>45811849 #>>45812998 #>>45813114 #
locknitpicker ◴[04 Nov 25 16:44 UTC] No.45812998[source]▶
> Stack enough layers - framework on library on abstraction on dependency - and nobody understands what the system does anymore.

This is specious reasoning, as "optimized" implementations typically resort to performance hacks that make code completely unreadable.

> 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.

I think you're confusing things. Bloat and lack of a clear software architecture are not the same thing. Your run-of-the-mill app developed around a low-level GUI framework like win32 API tends to be far more convoluted and worse to maintain than equivalent apps built around high-level frameworks, including electron apps. If you develop an app into a big ball of mud, you will have a bad time figuring it out regardless of what framework you're using (or not using)

replies(2): >>45813940 #>>45814369 #
1. adamzwasserman ◴[04 Nov 25 18:01 UTC] No.45813940[source]▶
I'm not advocating for unreadable optimization hacks. I'm working within TFA's own framework. TFA argues that certain bloat (frameworks, layers, abstractions) is justified because it improves maintainability through "modularity, extensibility, code patterns."

I'm saying: those same layers create a different maintainability problem that TFA ignores. When you stack framework on library on abstraction, you create systems nobody can hold in their head. That's a real cost.

You can have clean architecture and still hit this problem. A well-designed 17-layer system is still 17 layers of indirection between "user clicks button" and "database updates.