There's a stat I think quoted in "Code Complete" by McConnell that says the number of bugs in a system strongly correlates with the number of coders. The conclusion is that as the # of coders goes up, the # of lines of communication between them grows exponentially, and it's the lines of (mis)communication that lead to bugs.

This:

1. explains Brooks' assertion that adding coders to a late project makes it later

2. emphasises the importance in clearly defining interfaces between components, interfaces being the "paths of communication" between the coders of those components.

So your assertion is well founded.

I mean, microservices split the code into smaller chunks but now lots of little pieces communicate over the network and unless you are using some form of RPC, this communication channels are not typed and there's a lot more stuff that could go wrong (packets dropped, DNS not resolving). Plus you could update one microservice and not update its dependents. I think a lot of people jumped on the hype without realising that it's a trade-off

I work at a largish org (where microservices make sense but there are monoliths too) and the scary bits are unowned functionality. Leaning into a platform but being a business it isn't pure generic like say AWS it knows ahout the business. Some features are distributed across dozens of services. It is a skill hunting down who to blame for a problem. Not blame, ask for help, of course ;)

Look at Mr. Never seen an off by one error over here. I realize that putting a remote service call in between functionality adds complexity, but this is just so laughably hyperbolic.

I've found fencepost errors but AFAICR it was always somebody calling somebody else's code with the wrong semantics.