[hmeh]

It’s hard to imagine worse advice. Software design principles lead you to good architecture. Focus on autonomy, proper partitioning, and sound design and you get what you get. If you target monoliths out of some misguided attempt to reduce cognitive load, you will only create unnecessary entanglement. If you try to target “microservices” with N services per team or other arbitrary target, you will end up missing boundaries you should realize or introducing ones you shouldn’t.

There is no instant pudding.

[hmeh]

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.

[dboreham]

The entire purpose of microservices is to comply with Conway.

[hmeh]

Source: I lead a team of a dozen or so and we have over 100 deployed components. We don’t call them microservices, because we aren’t web developers pretending to do architecture and recreating the mistakes of DCOM, CORBA, and Web Services. Most of them are autonomous event sourced components. The others are stand alone web applications that are stitched together with Nginx routing and SSI. The user has no idea they are interacting with 100 apps, but the devs sure do.

[hmeh]

This is wrong. That's not how Conway's Law works. It’s also not how software design works. But please, by all means, continue to spread disinformation and keep us in the dark ages.

[guhcampos]

I don't disagree completely with the comment, but I would possibly change it from "comply with Conway" tô "embrace Conway".

[hmeh]

If you don't disagree, then I assume you have a strong understanding of structural design. I assume that you recognize that Conway's law is more of a curse, and a warning than it is something to embrace. I assume that you recognize that the only possible way to "embrace conway's law" and simultaneously recognize structural design would be to constantly be firing or otherwise disbanding entire teams as components get completed (components that likely won't need to be touched frequently because they were designed for a single reason to change). I assume all of that makes perfect sense to you. Yes?

[guhcampos]

No, not at all. I see why you think of it as a curse, I don't enjoy it as a resulta, but it's an observation of a pervasive pattern, not a design decision. It emerges from the way humans communicate and organize themselves.

You can either fight it agressivelly and try to minimize it, or you can "embrqce" it and try to adapt. I could force it into a disability analogy:

if you become suddenly deaf, you can agressivelly try to reverse it by all medical means possible, and you might succeed. Or you might not, then it would be better for you to accept the fact you are deaf and design your life around this disability as a means to adapt yourself to it.

That's how I see microsservices, too: accepting that large enough organizations cannot communicate as effectivelly and efficiently as small ones, therefore designing systems to minimize the impacts of these communication failures.

[feoren]

A cynical take is not "disinformation". Let's not dilute that word.