5 ms·

Very few people ever even attempt to write "lean software". The definition is a little nebulous, but "software without bloat" is a good one. This means that you

Very few people ever even attempt to write "lean software". The definition is a little nebulous, but "software without bloat" is a good one. This means that you have few dependencies, and the ones you have themselves have few dependencies, for a starter. But right there you have the first problem, which is that dependencies grow stronger with the number of users, and the number of users grows with applicability, hence the rise of dependencies that no-one uses more than 20% of, but everyone uses a different 20%. Even if you do tree-shaking or something so that you at least don't pass on the complexity you're not using, it still doesn't feel lean, because you're cognitively bloated, so to speak. Then, if you rewrite the library (because extracting your 20% is going to be very painful) you can make it simple and small, but no-one is going to use it but you and so it will remain weak, tightly coupled to the one project that uses it, because it doesn't offer the breadth of features people need. The other reason software bloat persists is because knowing enough about the runtime of your software to even be offended by the presence of bloat is exceedingly rare. Repetitious and pointless tasks abound in modern software, where work is done at one layer and then thrown away and redone by another, repeated N times. But to even know about this requires that you understand your runtime and what its doing in your case, and in our industry, ignorance is (economic) bliss, where "go along get along" is richly rewarded and any aesthetic or moral objection to how things are done is harshly punished. Strong and real social and economic forces drive bloat and punish the individual that would combat it. Which is why those who make the (at some level, doomed) attempt to fight bloat deserve at least our respect and some honor, since they will not only not receive thanks, they will be actively attacked by those who (correctly) perceive their work as a challenge to the status quo, and hence dangerous, unwanted, and a target.

deterministic 3y ago
Not my experience. I write high-performance business/enterprise software every day and get rewarded for it. Keeping the architecture simple but fast by design makes everything so much easier and productive. I really wish developers would take responsibility for their own low performance code instead of blaming everybody/everything else.
crq-yml 3y ago
It's more nuanced than that. A large share of software bloat is tied to awkward combinations of device convergence and modularity. I'll give an analogy with pens: * Dip pens and brushes, the original inking tools, rely on the user having a pot of ink available and some fine-pointed object capable of holding the ink. It's very simple, but this two-piece design limits situational use and requires the tip to be scrubbed off like used silverware. But you are relatively unlimited in what you put in the ink and the style of the nib, making it one of the best artist's tools even today. * Fountain pens innovated by creating a reservoir inside the pen, and a feed mechanism. This creates a modular pen body, allowing the user to customize a body with different inks, reservoir mechanisms(cartridge, piston, etc.) and nibs. However, the ink has to be liquid enough to gravity feed, and cleaning the pen and fixing feed issues is a more involved process, making fountain pens reputed as a temperamental platform with many tradeoffs for portability. Disposable ballpoints and markers devised a one-size-fits-all solution: make refills be the "whole pen", comprising tip and reservoir, and leaving the body as just a shell. This has allowed the designs to become very intensively engineered, with customized gel ink formulas, rubberized marker tips, etc. However, most of these designs are not made for longevity in some dimension - gel refills dry up, oil-based refills fade, marker tips get smashed. As well, there is a limited range of line styles achievable from a ball or marker. Lastly, there is a recurring Kickstarter scam in which a "printer pen" is demonstrated, with selectable RGB color. Besides the fact that this product doesn't really exist, it would make the pen into something even more complex than a fountain pen. So in solving technical problems, I think computing necessarily converges on answers similar to how pens are engineered: if you want it to be very simple and exacting, it's a dip pen, and you have to "plug it in" each time. If you want it to be easy-use, to last a while and to get out of the way, you want a pack of Bic ballpoints. If you want some mix of those things, you end up in the space of markers or fountain pens. But software lets us make the RGB pen, actually have it work and be used by people. And that is a problem, because now our expectations are that nobody should have to use a dip pen ever again, when a large part of the population didn't even get exposed to them and lacks the agency to choose.
scotty79 3y ago
Shouldn't our tools be able to remove unused parts of the dependencies?

deterministic 3y ago

Not my experience. I write high-performance business/enterprise software every day and get rewarded for it. Keeping the architecture simple but fast by design makes everything so much easier and productive. I really wish developers would take responsibility for their own low performance code instead of blaming everybody/everything else.

crq-yml 3y ago

It's more nuanced than that. A large share of software bloat is tied to awkward combinations of device convergence and modularity. I'll give an analogy with pens: * Dip pens and brushes, the original inking tools, rely on the user having a pot of ink available and some fine-pointed object capable of holding the ink. It's very simple, but this two-piece design limits situational use and requires the tip to be scrubbed off like used silverware. But you are relatively unlimited in what you put in the ink and the style of the nib, making it one of the best artist's tools even today. * Fountain pens innovated by creating a reservoir inside the pen, and a feed mechanism. This creates a modular pen body, allowing the user to customize a body with different inks, reservoir mechanisms(cartridge, piston, etc.) and nibs. However, the ink has to be liquid enough to gravity feed, and cleaning the pen and fixing feed issues is a more involved process, making fountain pens reputed as a temperamental platform with many tradeoffs for portability. Disposable ballpoints and markers devised a one-size-fits-all solution: make refills be the "whole pen", comprising tip and reservoir, and leaving the body as just a shell. This has allowed the designs to become very intensively engineered, with customized gel ink formulas, rubberized marker tips, etc. However, most of these designs are not made for longevity in some dimension - gel refills dry up, oil-based refills fade, marker tips get smashed. As well, there is a limited range of line styles achievable from a ball or marker. Lastly, there is a recurring Kickstarter scam in which a "printer pen" is demonstrated, with selectable RGB color. Besides the fact that this product doesn't really exist, it would make the pen into something even more complex than a fountain pen. So in solving technical problems, I think computing necessarily converges on answers similar to how pens are engineered: if you want it to be very simple and exacting, it's a dip pen, and you have to "plug it in" each time. If you want it to be easy-use, to last a while and to get out of the way, you want a pack of Bic ballpoints. If you want some mix of those things, you end up in the space of markers or fountain pens. But software lets us make the RGB pen, actually have it work and be used by people. And that is a problem, because now our expectations are that nobody should have to use a dip pen ever again, when a large part of the population didn't even get exposed to them and lacks the agency to choose.

scotty79 3y ago

Shouldn't our tools be able to remove unused parts of the dependencies?