←back to thread

Some software bloat is OK

(waspdev.com)
50 points senfiaj | 3 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 #
1. frisbee6152 ◴[04 Nov 25 15:08 UTC] No.45811849[source]▶
A well-optimized program is often a consequence of a deep understanding of the problem domain, good scoping, and mindfulness.

It often feels to me like we’ve gone far down the framework road, and frameworks create leaky abstractions. I think frameworks are often understood as saving time, simplifying, and offloading complexity. But they come with a commitment to align your program to the framework’s abstractions. That is a complicated commitment to make, with deep implications, that is hard to unwind.

Many frameworks can be made to solve any problem, which makes things worse. It invites the “when all you’ve got is a hammer, everything looks like a nail” mentality. The quickest route to a solution is no longer the straight path, but to make the appropriate incantations to direct the framework toward that solution, which necessarily becomes more abstract, more complex, and less efficient.

replies(2): >>45812116 #>>45813549 #
2. adamzwasserman ◴[04 Nov 25 15:32 UTC] No.45812116[source]▶
I completely agree. This is the point I make here: https://hackernoon.com/framework-or-language-get-off-my-lawn...
3. ElevenLathe ◴[04 Nov 25 17:27 UTC] No.45813549[source]▶
The main point of the framework is to keep developers interchangeable, and therefore suppress wages. All mature industries have things like this: practices that aren't "optimal" (in a very narrow sense), but being standardized means that through competition and economies of scale they are still cheaper than the alternative, better-in-theory solution.