It's not microservice or monolith; it's cognitive load

Yes, let's. I have no problem with push back.

> You have experienced what happens when web developers cosplay as software architects.

I agree that this is overly snippy to the point of being counter-productive. It represents a particular emotional frustration with the state of our industry. We knew what ended up being microservices (web API servers making web API calls to other web API servers) was a failure mode. We knew you couldn't just introduce network hops and call it "architecture". So yes, I'm annoyed about that such that I'm willing to call out nameless "web developers", but I understand how that can create discomfort.

> That is, you experienced an average team doing average work misguided by average bad advice. It says absolutely nothing about software design. It only speaks to the fat part of the bell curve doing what it always does.

Indeed, and the person I was responding to effectively acknowledged this. The sooner we can recognize that the skill curve/technology adoption curve are real things, and crossing the chasm takes hard work, the sooner we can stop leaving people behind said chasm. It's not easy. Nothing I said here is untrue. If it is, please point it out.

> because, unlike them, I have significant material experience in both camps.

Again, I'm pointing to a material difference. Most people who are attempting to refute what I am saying have never done what I am saying. They are doing it from a position of fear, uncertainty, and doubt, or worse. I've been where they are. I've fought the fight they are fighting and, thankfully, I lost, and was introduced to new ways of doing things and seeing things. If a person has done what I'm discussing, I would expect them to say that and tell me why it failed. Instead I get people telling me it can't work and I'm incompetent, etc.

> It’s hard to imagine worse advice. > Just read the author’s bio. This is a person that appears to have zero software design experience writing an article telling you to ignore software design and just respect your team configuration. I call this Conway’s Confusion.

Putting these together because they are about the OP article and the OP. "hard to imagine worse advice" is hyperbole, but it is bad advice. You can't force fit concepts to teams. I mean, you can try, but you'll always end up with unnaturalness.

The actual OP's bio talks about their career. None of it mentions software design. If a person with zero surgery experience started writing about how to properly set up operating rooms, you can darn well bet they will be called a charlatan and called to the carpet. If they aren't people may die. Software isn't that serious usually, but it's not hard to imagine that there have been billions upon billions of dollars flushed down the toilet for the sake of poor software design that no one speaks out against.

> But please, by all means, continue to spread disinformation and keep us in the dark ages.

Yes, overly cynical and unnecessary. I made my point prior to this and I didn't need to add this.

> That sets a good friendly tone huh? If you can't take push back, don't be an arse to begin with.

Some was unnecessary yes, thanks for calling it out. The rest represents what I think is healthy push-back against an orthodoxy that causes more harm than good. We can achieve more as an industry and make our way out of the realm of hobbyists and into something more serious. Many of us call ourselves engineers, but nothing we do resembles anything that people who are actually classically trained engineers do.

> > And which part, specifically sounds incompetent? I’m happy to discuss that.

> Your arrogance precludes a fruitful discussion. But I believe that this needs to be called out, if nothing else to nudge other people to also do it when they see it, or to, albeit much less likely, nudge you towards eating some humble pie.

Just to be clear: you said that what I was saying sounded incompetent. I asked you about that, and you're telling me I appear to be too arrogant for you to tell me why I sound incompetent? Please, tell me what I said that sounds incompetent. Let's move past the ad hominem portion of the discussion now and talk about the actual substance. I'll do my best to refrain from hyperbole and unnecessary snark.

How so? Why don't we put our Rails applications in the Rails repository?

> And IMO invoking Plato to make a point is not helpful. Argumentum ad antiquitatem

What I am pointing to is a common thread. Plato, Christopher Alexander, Edwards Deming, etc. What I am arguing for is anything but common tradition. It's counter to what is current "common knowledge".

> This goes for the “30 years” comment as well: it’s entirely conceivable that they’ve been doing things inefficiently for 30 years.

Yes, entirely possible. And if we find a better way to do things, we will be first in line.

> More likely that there is such a huge sunk cost that they are heavily invested in justifying it.

What's your evidence of this?

A lot of customer value comes from companies that assemble ideas that have existed in isolation. Customers think they hate that, but the numbers say they are wrong.

Foods are an early example. Most are rearranging the same dozen ingredients in different quantities and orders of operation.

Vertical integration is not an all or nothing proposition. Companies can make pretty unique solutions by specializing a couple of pieces.

Usually my advice for anyone thinking about building a new piece of software for a particular business goal is to a) run an event storming workshop with a group of domain experts to help get a really good idea of events, actors, commands, information flow and clusters of behaviour, and then b) run a second pass where you think the domain through in terms of transactional boundaries and DDD aggregates, and then c) do a third pass where you think specifically about security constraints and how they can be met.

It's an expensive exercise in terms of time taken up front, but having completed it, hopefully the team have gained enough of an insightful understanding of the domain that they won't make silly hard-to-reverse mistakes like needing transactions that span service boundaries, or building demonstrably distinct domains which share similar concepts into uber objects spanning those domains, or having one service depend on information from multiple other services in order to apply required security constraints.

Anyway, TLDR is I have found DDD and DDD-adjacent methods extremely helpful for thinking through designs and making app architecture decisions.

I used a workflow as a common type of SAAS business. My past and current companies could be considered such companies and had significant resources into such streams. Trying to enable the workflow of thousands of companies is a remarkably difficult problem.

But to take an example, look at monday.com as a workflow SAAS business that has a 9 billion dollar market cap. I would be surprised if they didn't have at least one team dedicated to tools for their support team.