Comment by kamaal

Its almost an everyday song that I hear, that big companies are full of hundreds or thousands of employees doing nothing.

I think sometimes the definition of work gets narrowed to a point so infinitesimal that everyone but the speaker is just a lazy nobody.

There was an excellent article on here about working at enterprise scale. My experience has been similar. You get to do work that feels really real, almost like school assignments with instant feedback and obvious rewards when you're at a small company. When I worked at big companies it all felt like bullshit until I screwed it up and a senator was interested in "Learning more" (for example).

The last few 9s are awful hard to chase down and a lot of the steps of handling edge case failures or features are extremely manual.

> In this microservices world, things are small enough that any small group of even low productivity employees can make things work. That is quite literally true, because smaller things that work well don't even need all that many changes on a everyday basis.

You're committing the classic fallacy around microservices here. The services themselves are simpler. The whole software is not.

When you take a classic monolith and split it up into microservices that are individually simple, the complexity does not go away, it simply moves into the higher abstractions. The complexity now lives in how the microservices interact.

In reality, the barrier to entry on monoliths wasn't that high either. You could get "low productivity employees" (I'd recommend you just call them "novices" or "juniors") to do the work, it'd just be best served with tomato sauce rather than deployed to production.

The same applies to microservices. You can have inexperienced devs build out individual microservices, but to stitch them together well is hard, arguably harder than ye-olde-monolith now that Java and more recent languages have good module systems.

There are two freight trains currently smashing into each other:

1.) Elon fired 80% of twitter and 3 years later it still hasn't collapsed or fallen into technical calamity. Every tech board/CEO took note of that.

2.) Every kid and their sister going to college who wants a middle class life with generous working conditions is targeting tech. Every teenage nerd saw those over employed guys making $600k from their couch during the pandemic.

Well yeah... computers are really powerful. you don't need docker swarm or any other newfangled thing. Just perl and apache and mysql and you can ship to tens of millions of users before you hit scaling limits.

Amazon has been at the forefront of micro services at scale since 2002.

https://nordicapis.com/the-bezos-api-mandate-amazons-manifes...

> If this hadn't been the case, the industry as a whole can likely work with 40% - 50% less people eventually. Thats because at any given point in time even with a large monolithic codebase only 10 - 20% of the code base is in active evolution, what that means in microservices world is equivalent amount teams are sitting idle.

I think it depends on the industry. In safety critical systems, you need to be testing, making documentation, architectural artifacts, meeting with customers, etc

There's not that much idle time. Unless you mean idle time actually writing code and that's not always a full time job.

I think most people misunderstand the relationship between business logic, architecture and headcount.

Big businesses don’t inherently require the complexity of architecture they have. There is always a path-dependent evolution and vestigial complexity proportional to how large and fast they grew.

The real purpose of large scale architecture is to scale teams much moreso than business logic. But why does headcount grow? Is it because domains require it? Sure that’s what ambitious middle managers will say, but the real reason is you have money to invest in growth (whether from revenue or from a VC). For any complex architecture there is usually a dramatically simpler one that could still move the essential bits around, it just might not support the same number of engineers delineated into different teams with narrower responsibilities.

The general headcount growth and architecture trajectory is therefore governed by business success. When we’re growing we hire and we create complex architecture to chase growth in as many directions as possible. Eventually when growth slows we have a system that is so complex it requires a lot of people just to understand and maintain—even if the headcount is longer justified those with power in the human structure will bend over backwards to justify themselves. This is where the playbook changes and a private equity (or Elon) mentality is applied to just ruthlessly cut and force the rest of the people how to keep the lights on.

I consider advances in AI and productivity orthogonal to all this. It will affect how people do their jobs, what is possible, and the economics of that activity, but the fundamental dynamics of scale and architectural complexity will remain. They’ll still hire more people to grow and look for ways to apply them.

It would be sad if you are correct. Your company might not be able to justify keeping dozens and hundreds of teams employed, but what happens when other companies can't justify paying dozens and hundreds of teams who are the customers buying your product? Those who gleefully downsize might well deserve the market erosion they cause.

This is blatantly incorrect. Before microservices became the norm you still had a lot of teams and hiring, but the teams would be working with the same code base and deployment pipeline. Every company that became successful and needed to scale invented their own bespoke way to do this; microservices just made it a pattern that could be repeatedly applied.

I think that the starting point is that productivity/developer has been declining for a while, especially at large companies. And this leads to the "bloated" headcount.

The question is why. You mention microservices. I'm not convinced.

Many think it is "horizontals". Possible, these taxes add up it is true.

Perhaps it is cultural? Perhaps it has to do with the workforce in some manner. I don't know and AFAIK it has not been rigorously studied.