there's a certain kind of linux hobbyist who believes that software minimalism (understood variously as adhering to the unix philosophy, using as few resources as possible, or avoiding some other form of "bloat") is a non-negotiable good. starting from this premise, they hypothesize a range of possible explanations as to why most software does not meet their preferred criteria. sometimes these hypotheses are reasonable: developers now have far more resources at their disposal, so software uses more resources because it can. other times they are idiotic: tech companies are all "woke" now, meaning they hire women, minorities, and men made effeminate by soy (i guess?) instead of good programmers. back in the day, this brand of moron would have appealed to affirmative action as an explanation, but now that even the sweatiest cable news host no longer pretends that affirmative action programs still exist in any meaningful capacity, they can only gesture at some vague tendency in corporate culture.

there are a couple basic problems with this kind of chatter, even in its not-stupid forms. the fundamental problematic assumption is that minimalism is a non-negotiable good of the highest priority, i.e., that every non-soy developer shares the exact same understanding of what objectively Good Programming looks like. this obviously isn't true. simplicity and minimalism are usually purchased at convenience and how much (or what kind of) convenience you're willing to trade for their sake is going to depend heavily on your use case. there's a reason, for instance, that systemd remains the default solution in most linux distributions, and it's not effeminacy or incompetence on the part of the development teams. the very thing that many desktop minimalists dislike about systemd (call it bloat, feature-creep, not adhering to the unix philosophy, whatever) was at the core of its pitch from the beginning. it's a conflict between "incommensurable conceptions of the good," if you'll indulge me.

that said, even the talk radio form of the complaint isn't wholly incorrect: there is a general tendency of corporate culture toward more convoluted and sloppier code, but it has little if anything to do with wokeness, political correctness, or diversity training. when elon musk (no fan of "wokeness," grok aside) took over twitter, he began demanding that every developer at the company literally print out their code so they could show him how much code they'd written, evidently with the assumption that if you aren't constantly writing new code, you aren't really working. this is such a plainly stupid way of thinking about programming that it's difficult to put into words, but i think it's more common among tech ceos than we might like to believe. the crypto speculation bubbles, arbitrary layoffs, and dogshit worthless LLM "assistants" crammed into every piece of commercial software in the last few years all suggest that tech execs are petty despots with no actual skills besides sniffing out easy money and contriving paper-thin justifications for fucking everyone else over once it dries up. the fish rots from the head. baldur bjarnason has made a compelling argument that bloated technologies become standards because they enable deskilling and labor arbitrage. even if we grant that programmers are less competent today than they were fifty years ago, then this is almost certainly a symptom and not the underlying illness.

by point of contrast, let's consider how our early heroes of software engineering worked. bell labs, xerox parc, and similar hubs of invention were the research branches of highly profitable companies or university research centers, sometimes floated by military or other public sector largesse, sometimes incorporated as part of a legally regulated monopoly, but in every case insulated from market competition—or to put a finer point on it, from the need to ship a general consumer product. the early unix tools were developed for very specific, usually academic applications, which is why so many of them focused on manipulating text and formatting documents. grep, in the familiar story, was developed by ken thompson to help lee mcmahon analyze the federalist papers. these were (are) tools intended for narrow professional uses, developed by people who, enviably, never had to worry about marketing or profitability. would that all software could be produced under such conditions, but alas, 'tis not so. it takes a mission-driven organization like suckless e.V. and/or a volunteer effort to arrive at the same kind of discipline and philosophy of design so common to those postwar research centers. and these projects can adhere to this particular set of principles because they have tailored their audience in advance to a small set of users who are happy to work things out at least partly on their own. suckless is explicit about their preference for a "small and elitist" userbase.

the final, most benign reason that most consumer software is bloated (the final that i'll opine on anyway) comes down to time and scale. microsoft office is a disgusting mess that i suffer for every second that i have to use, but it got that way for a reason. literally a billion people use microsoft office in some capacity, those billion people speaking hundreds of different languages, each using office something slightly different. microsoft is in the position of needing to keep all their existing users happy (especially enterprise users), which means decades of backwards compatibility and keeping legacy functions intact, while also attracting new ones. this is a basic problem of social complexity and bureaucracy. when you need to please a billion people, you need to keep a lot of stuff around that is useless to the vast majority of them. when you need to continue attracting people beyond that billion, you need to add more stuff that is useless to the vast majority of them. the same problems of coordination that produce piles of redundant forms when you start a new job or renew your passport also produce the byzantine menus and dialogues in enterprise software.