Microservices aren't the problem. Incompetent people are

they're called juniors and every other industry has seniors to help guide them and ensure they don't make major mistakes.

Except in our industry. In our industry the juniors often are the ones making the decisions.

Inexperienced engineers aren't the problem. Juniors will submit spaghetti code messes, but those can be cleaned up without too much trouble. The real problem is incompetent people higher up that can make large scale architecture and design decisions. e.g. somewhere I used to work there was a VP that decided to hand roll an ORM instead of just using Django.

> I feel like there is an unfair sentiment of competence elitism in the software engineering world.

And I feel like there are people in software that complain about things like "competence elitism" when other industries encourage doing things right.

Take actual engineers, for example:

https://www.nspe.org/resources/ethics/code-ethics/engineers-...

I've seen clients run automated architecture tests with varying degrees of success. These reduce damage done by juniors.

For example tests that ensure that controller actions don't create SQL queries directly but instead always use repositories/services/models (whatever you call data fetching layer).

Another example is a test that ensures that there's no "print" in data fetching layer, only allowing them in HTTP controller actions.

That's the gist of it.

> There's also nothing wrong with engineers who program exclusively to collect a paycheck and aren't actually passionate about their work. I believe this is an inevitable side effect of the accessibility of programming today.

I only agree if the person who lacks passion can actually do the job and has experience. The trouble with programming computers is that you cannot get sloppy with the implementation details or design decisions. It is absolutely not a field accessible to people who guess too much and code by coincidence.

Often those details are also overlooked at the project planning level so it's unfair to everyone else who has to pick up their slack. It's already bad enough that the people in charge usually don't understand the project very well.

This sounds in line with Google creating go: restrict the language features so you can hire mass quantities of programmers and be reasonably sure they won’t go off the rails. It’s fine for what it’s for but doesn’t seem like that should be the goal of most programming projects?

Especially with AI copilots getting better, it feels like we’re headed for a point where you’re either capable of architecting complex systems, or there isn’t much software for you to write: other industries tend to have rote work for beginners while they gain skills, but in software rote work tends to get automated away. AI can help people learn faster, but given what AI has proven good at, I expect more of the gains will go to expert productivity. (or non-programmer domain experts)

I'm sorry if it came across this way. It was definitely not intentional! My opinions perfectly match yours, in fact :)

I did try to point out that I don't really blame normal devs but the leadership instead. A fish rots from the head. My writing skills are just not that good (yet) :)

I also used "incompetence" very broadly which was probably a mistake from writing perspective. From bad management decisions all the way to brilliant engineers simply not being familiar with a particular technology/paradigm.

Enough things are wrong win this comment that I can't be bothered to skim it.

If you're going to make claims that micro-services are failing at 9/10 companies you really should have a source.

Agreed. This is like blaming the user for your bad UX. Nope, the solution increased the complications of a very complex problem set (scaling software development).

There are no silver bullets that can solve this. Only well-designed systems accommodate for the flexibility of human error and hubris can do that.

Yeah, it is a bit of a blanket statement, and it's quite common to headline with provocation, but there are some good things in here. He admits upfront that MS is his personal preference.

> I understand it’s a harsh title and at times a harsh essay. Such is life. All opinions are my own.

Some takeaways you might have missed:

* Use the right tool for the job - one-tool shops are bound to fail

* (Similar to above) There is a tendency to find _a_ solution rather than the _optimal_ solution

* The engineering halo effect is real and prominent

Then the author goes on to provide some possible solutions:

* Using the SOLID framework for building

* Use services

* KISS

* Developer experience is very important

* Protect your time and your work

* Governance is required to enforce certain principals.

I don't agree with all of these, but they are certainly worth considering.

> But the attitude that "X that fails at 9/10 companies isn't the problem, we just need to change millions of engineers" is a naive attitude.

It's even worse than naïve, it's a literal fallacy, a "No true Scotsman" with technology.

System resilience is important at scale, and resilience includes being resilient to the failures in the human component of development; if a system depends that every one developing it to be a master of the underlying foundation then you'll require lots of very specialised, competent people who mastered the technique. That is very costly, if microservices depend on high mastery then we should budget the cost of the talented people required to run it.

My experiences with how to successfully deploy microservices include much the opposite: giving tooling to incompetent people to avoid the worst footguns, training them in best practices over time while designing an architecture that is somewhat resilient to their inevitable failures, one that is easy to be fixed when they've learned how to best use it.

> "X that fails at 9/10 companies isn't the problem, we just need to change millions of engineers"

And even in those 9/10 companies, the failure doesn't even prove that the engineers are the ones unable to create meaningful service boundaries, within a monolith or distributed to multiple services. All of those engineers have bosses and, I don't know what others are seeing, but I feel like I've seen Software Development Manager increasingly become Manager of Software Developers.

I suggest that those same management structures which failed to enable their engineers to create meaningful service boundaries in their monolith, which led to the desire for a cure-all solution, also failed to manage (or protect) their developers such that those developers _could_ turn the existing system architecture into one based on microservices.

Technical leadership has just become increasingly abysmal. Developers are tasked to fulfill user stories but those are often written in a way that completely ignores the technical work required to fulfill such a story. That creates a painful disconnect between expectations and reality, even in 90% CRUD, monolith web apps. Even in a monolith with proper separation of concerns, its easy to imagine one service being the "user" of another service for the purpose of more granular and clear tasks but, "that's not how user stories work." :(

This is my main gripe with some newcomers of projects I have worked on.

They tend to spit out destructive criticism towards legacy code with such an ease and without any context on why things are the way they are.

My usual response, albeit in a more polite manner, is something along the lines of:

"Yes I know the code in this part of the system is not as nice as other parts. And if you bothered to ask why, I'd tell you it's because this code is 6 years old and we learned better ways to do the same thing since. It's called technical debt and we are always working to reduce it. There's no need to demoralize the engineers that worked on that part of the system."

> Instead of being cool, focus on solving your problems.

This needs repeating to every dev every week. Myself included

Microservices are a solution to an organizational challenge: how do we set clear boundaries of ownership within a complex system? From a technical perspective there are pros and cons.

Unfortunately, I don't see a wealth of other ready-made practices for companies to copy when they grow and need to solve this problem. I once worked on an enormous Rails monolith that was very well organized and had layered on several additional patterns to improve modularity and maintainability. Still, a SEV in a minor product area could (and did) bring down the whole system, and they were in the process of dismantling it.

> avoid hiring people who jump companies every couple year

You don't get many of those people any more, because just about every other employer has burned that bridge to the ground. People, especially the young ones who entered their careers around the 2008ff megacrisis, have zero trust left in anyone.

When companies don't care and ditch us at the first sign of problems (easy, because we were the freshest hires), why should we show any sign of loyalty in return? If you want loyalty, pay us.

In the late 90's and early 2000's I learned all that data structure stuff but that was mostly in the first 2 years. Beyond that many classes were about software engineering, project management, etc. I learned Agile (then in it's infancy) as well as doing a complete waterfall project (which turned out poorly -- as expected). But even at that time most other schools did not offer those kinds of courses in their CS education.

In contrast, I've worked on 2 UI frameworks and knowing all about tree traversal was super useful.

I've sat next to the engineer who had to write various sort algorithms for the embedded runtime I helped design.

I've witnessed a file system get implemented from scratch.

I have walked through the Windows' kernel source code and knowing my fundamentals sure as heck helped to keep me grounded.

> (and if there aren't, that's often a big red flag that you're doing something wrong).

Or that you've chosen a career building the layers that underpin everything else.

I've found that life is more enjoyable when I understand how things work at a base level, and remembering my fundamentals opened up doors to work on cool projects.

I think "most of what I learned is inapplicable to my job" is kind of inevitable in any CS program that tries to expose students to a breadth of topics before they graduate and get hired into specialized jobs. The trick is that the "most" will vary from person to person.

As a fellow 1980s CS person, I too got a lot of DSA coverage, but I ended up using a respectable amount of it when I was working at low-level systems programming jobs. I have never used what I learned in my computer graphics class. But I had classmates who went into animation and used that stuff every day.

Agreed about the lack of any education about the "engineering" side of the work, though. One challenge is that engineering is mostly a group activity but education is focused on individual learning. With some exceptions, you don't get a group grades in classes, and usually, collaborating with other students on your homework or your tests is considered "cheating" rather than "teamwork." Professors aren't in the habit of repeatedly changing the assignment out from under you while you're halfway finished, but dealing well with unpredictably shifting requirements is a huge part of the job.

But CS is not engineering, CS is a branch of mathematics. I studied Finance at university and I've seen people complaining how it doesn't teach you how to invest in stocks and do M&A. Later, talking to professionals about what they do in their jobs I realized that what I'm being tough is adjastent, but they are not preparing you for a job. It's not like medicine where you get placements and they literally train doctors. Same with Computer Science, it's not software engineering and while the two are obviously adjacent. Damn I'm 6 years into my software engineering career as a self-taught guy, and I've contributed, implemented, and released projects that work well in the real world for non-trivial companies, but I am only now learning about algorithms and CS theory as a side project.

I think bootcamps try to fill that field but most of the ones I've seen are quite trivial, getting you through the basics. If you're asked to implement 10 greenfield CRUD APIs and then go to a job and have to maintain some huge monolithic repo it's going to be hard.

I think an educational approach where the curriculum involves some sort of "For this task, you have to change this thing in this codebase and deploy it without crashing the thing", "refactor this code base", giving people some sort of project and then switching it up in the middle would be valuable because it's mostly what software engineers do day to day: write tests, fix bugs, implement features in existing projects.

Bingo. Design for incompetence. There are few codebases in this world that don't need incompetent people to contribute to them. (This is typically driven by business incentives)

If you get to work on one of those codebases ... good for you. The rest of us are just trying to gatekeep piles of shit from getting in while being pushed by management to open the flood gates.