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 dis-
posal, so software uses more resources because it can. other times
they are idiotic: tech companies are all "woke" now, meaning they
hire women and minorities 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,
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 (see 0pointer.net/blog/projects/why.html). 
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
enterprise software in the last few years all suggest that many tech
execs are petty despots with no skill beyond sniffing out easy money
and fucking over their employees when it dries up. companies do not
use bloated frameworks because the dumb broads they hire make them;
this gets the causality precisely backwards. the fish rots from the
head. baldur bjarnason makes a compelling argument (baldurbjarnason.
com/2024/react-electron-llms-labour-arbitrage) that these frameworks
become standards because they enable deskilling and labor arbitrage.
even if we grant that programmers are less competent today by some
illusive metric, this is a symptom and not the underlying illness.

in contrast to the present, 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 compan-
ies or research centers at major universities, sometimes floated by
military largesse or incorporated into a 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, commonly academic
applications, which is why so many of them focused on manipulating
text and formatting documents. grep and sed were famously developed
to help sort out authorship controversies re: the federalist papers.
these are tools intended for narrow professional uses, developed by
people who, enviably, never had to worry about marketing or profits.
would that all software could be produced under such conditions, but
alas, it is not so. it takes a mission-driven nonprofit organization
like suckless e.V. and/or a volunteer effort to arrive at the same
kind of discipline and philosophy of design now. 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, to
take the obvious example, is explicit about their target audience
being "expert" users, their userbase "small and elitist," hence they
don't bother to write documentation (documentation is bloat).

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 need-
ing 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 users. when you need to continue
attracting people beyond that billion, you need to add stuff that is
also useless to the vast majority of users. the same problems of co-
ordination 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.