Comment by dvh | Hacker News Reader

Comment by dvh | Hacker News Reader

It was either here or on slashdot where I've read insightful comment on bloat, can't find it right now so I paraphrase:

People often think "speed" when they read "bloat". But bloat often means layers upon layers of indirection. You want to change the color of the button in one dialog. You find the dialog code, change the color and nothing. You dig deeper and find that some modules use different colors for common button, so you find the module setting, change the color and nothing. You dig deeper and find that global themes can change colors. You find the global theme, change the color and nothing. You start searching entire codebase and find that over 17 files change the color of that particular button and one of those files does it in a timer loop because your predecessor couldn't find out why the button color changed 16 times on startup so he just constantly change it to brown once a second. That is bloat. Trivial change will take you half a day. And PM is breathing on your neck asking why changing button color takes so long.

And sure enough, fourth slide mentioned speed.

I think of size when I read bloat. A simple HTML content page deeply nested DIV-soup and 14MB of JS and 2MB of CSS: bloat.

Bloat is code size/ program size that is not actually needed.

Bloated code bases are usually harder to work on and may have noticeable slowness: but not necessarily! Maybe the bloat of aforementioned HTML page is due to the use of a low/no-code framework that makes it suuuuper easy to maintain. And with internet being fast these days, many user may not notice 15MB "bloat" (=unneeded size), as the page also loads a video and several high-res images making the total add up to 60MB+ before all bells and whistles are showing.

EDIT: typo "internet being fat these days" -> "internet being fast these days"

I think of features. Code can always be fixed (in theory, at least: the Arrow of Software Development rarely points away from entropy), but "we're gonna strip this feature set back to basics" is even rarer.

I'd say: bloat = high size / features ratio.

For instance fresh install size: Puppy Linux 300MB vs Windows 11 24GB.

Sure Windows has some more features, but ratio wise it's a bloated monster.

http://puppylinux.com

Arguing features cause bloated businesses: https://www.seangoedecke.com/difficulty-in-big-tech/

Features is the better word, but code size is measurable. Everybody knows we shouldn't measure lines-of-code so we now use kB or MB as an equivalent for web sites

99.99% of source code is not Kolmogorov optimal.

This is a good thing.

The solution to the button problem is obviously to intercept the call to the underlying API that draws the button. Ideally, by having a generic interface so that you can change the "color override" behavior at runtime. It means that in the future, all you have to do will be to specify your behavior in a JSON file that is dynamically loaded. You can also leverage the already present JS interpreter to specify rules (keep things simple, we don't want to have another domain specific language). To make the code more testable, the JSON file reader will be abstracted away and "mockable".

Cue the dialog configuration service, which will provide dynamic dialog configuration JSON files.

The dialog configuration service will then need to communicate with the colour token service, which will be the single source of truth for the primary and secondary colour according to the current theme, so the dialog configuration service should only be concerned with the token representing the meaning it needs to communicate.

And of course, the colour token service will need to adapt to the device's detected ambient brightness level, so the colour token service should probably apply a luminosity transform as suggested by the ambient lightness service... but that math can get rather complex so I think I'll stand up a new colour transformer instead which can handle that along with hue shifting, just in case our brand colours all change by the same relative hue-degrees on a normalized sRGB colour wheel all at the same time.

Good talk team, we got a road map!

...and when the PM asks "why has this taken 3 years?", you explain on a whiteboard:

https://www.youtube.com/watch?v=y8OnoxKotPQ

Speed is a good proxy for bloat at human level. All the things you mention and that are mentioned in the slides have a cost paid in speed (among other costs discussed in the slides).

Reply on news.ycombinator.com