> Implicit in the author's reasoning is the principle that good engineers don't make mistakes; they don't break the build, not ever.
They don't, ever, because the VCS refuses a push if it breaks the build.
That's the problem with all those single-repo discussions. It works perfectly well if you have all the tooling that makes a single repo work like a multi-repo.
And it's great because you can enforce behind the scenes that everything is coherent... Except that you can enforce the same thing on a multi-repo if you write the equivalent tooling. All the points are completely moot, except the one that if you don't have a ton of tooling, a single-repo won't work at all, while a multi-repo will just be not great.
I actually tend to find the opposite - with a multi repo, CI/CD is often just plain broken and people waste significant amounts of time cargo culting working setups (and often do so badly or don't keep up with upstream changes).
They don't, ever, because the VCS refuses a push if it breaks the build.
That's the problem with all those single-repo discussions. It works perfectly well if you have all the tooling that makes a single repo work like a multi-repo.
And it's great because you can enforce behind the scenes that everything is coherent... Except that you can enforce the same thing on a multi-repo if you write the equivalent tooling. All the points are completely moot, except the one that if you don't have a ton of tooling, a single-repo won't work at all, while a multi-repo will just be not great.