[marhee]

The main reason for bloat not mentioned in the article is that most developers are not interested in the business domain of the company they are working for. They just want to do stuff with computers and software.

Which leads to adding stuff just for the sake of being of interest to developers. Think kubernetes, microservices etc. Secondly, because the developers are really not interested in the business (problems), they just want to easiest fix they can get away with. Which leads to bloat, as described.

A good test for this are feature specifications: if developers/programmers do not want to write them (or even don't read them with careful attention) then they are not interested in the problem domain of the company. It's an uncomfortable truth.

Another thing I've experienced is that non-technical management somehow wants to see solutions with loads of "technologies" included. I was once asked to give a diagram overview of our IT infrastructure. I agreed mentioning it would be a simple diagram (a reverse proxy, a server and a database). The simplicity of the diagram was frowned upon because if you look at all cloud platforms websites they make you believe that the IT infra for all companies must at least look like that of Amazon and Google.

So it is also a problem of management that does not want to reward simplicity and is victim of the "cargo cult" so eagerly fed by cloud providers.

[gregjor]

Exactly. Great comment.

Rob Pike (a few years older than me) didn't mention a few relevant facts. Those mainframes cost a small fortune, so their owners valued the computing resources. That pressure to control costs, along with the sometimes severe constraints of the hardware, forced programmers who cut their teeth in that era to avoid bloat and questionable features. For the first decade and half of my career I worked at companies that didn't have an "IT" or software development department -- I worked in business units like logistics or accounting, as part of those teams, rather than as a separate "resource." I knew what the business needed because I worked alongside the people who would use the code I worked on.

When I started freelancing about 15 years ago I ran into customer after customer who had got sold (or proposed) crazy over-complicated (and expensive) solutions. Very often it seemed like a shopping list of languages and tools of the day, put together with no regard for real business needs. I have listened to programmers bamboozle their bosses and customers with phrases like "performant" and "maintainable" and "best practices" that don't mean much and don't have objective ways to measure them. I don't usually ascribe that to malice or fraud, just an almost complete disconnect and lack of interest in the business and its needs.

[nyarlathotep_]

> So it is also a problem of management that does not want to reward simplicity and is victim of the "cargo cult" so eagerly fed by cloud providers.

This absolutely mirrors my experience. I've worked on large number of cloud projects that were monstrosities of containers, serverless functions, NoSQL DBs, CDNs, cross-account pipelines, piles of terraform/CFN etc etc.

Naturally this was all topped off by some React thing with "tailwind" or MaterialUI, so clients needed multiple MB downloaded to display a list or whatever.

These were ALL projects that could have had every requirement met by, like, Ruby on Rails on a Raspberry Pi.

The amount of time sunk into fiddling with IaC issues, or debugging 65 different serverless/container service integration was easily an order of magnitude larger than time spent delivering value to customers and end-users.

[7bit]

Kinda funny that you mention tailwind, as tailwind ships exactly the css that is needed to serve the design. Tailwind does not make your project bigger than not using tailwind.

[mediumsmart]

They probably referred to the percentage of bloated solutions with tailwind (100%) in the mix opposed to the percentage of lean solutions with tailwind (0%) in the mix which makes tailwind an indicator or cornerstone of a mindset rather than a contributor to the actual bloat which is kinda funny too of course.

[nyarlathotep_]

Correct. I'm referring to the mindset where "tailwind" (or whatever) is just "what you do" irrespective if it is even appropriate or not for the given solution. Same mindset as the architecture approach.

[aqueueaqueue]

Business problems aren't loved in interviews unless the next company is in the same business.

Therefore "I know React like a ninja" > "How cement companies transport concrete"

In addition companies fight to keep developers away from customers, with layers of business people and "requirements" that are "decrees".

[Gupie]

It also the fault of the guys in Marketing and Product Management who want features to match a competitor's, or to beat a competitor on some pointless metric, or to create different versions for different market segments, or because some corporate big wig made an off the cuff remark wouldn't it be nice if ...

[zabzonk]

> The main reason for bloat not mentioned in the article is that most developers are not interested in the business domain of the company they are working for. They just want to do stuff with computers and software.

Well, at the several investment banks I've worked for, the highest paid developers were those that also had the most knowledge of the bank's business. Of course, if you don't care about pay and just want to do "stuff", that's up to you.

[rob74]

> the IT infra for all companies must at least look like that of Amazon

Well, thanks to AWS, the IT infra for all companies increasingly does look like that of Amazon - because it's Amazon's own infra. Except if they're Azure or GCP customers, of course, but then it's M$'s or Google's infra...