It's kind of funny that the wisdom in software development is to program against interfaces and not implementations. And yet here we are with monorepos, doing

It's kind of funny that the wisdom in software development is to program against interfaces and not implementations. And yet here we are with monorepos, doing the big-ball of mud approach. I've worked on several multi-repo systems and several monorepos. I have a weak preference for monorepos for some of the reasons given, especially the spread of pull requests, but that's almost a 'code smell' in some respects. Monorepos that I've contributed to that have worked well: mostly one language (but not always), a single top-most build command that builds everything, complete coverage by tests in all dimensions, and the repo has tooling around it (ensure code coverage on check in, and so on). Monorepos that I've contributed to that haven't: opposites of the previous points. Multi-repos that have worked well: well abstracted and isolated, some sort of artefact repository (nexus, jfrog, whatever) as the layer between repos, clear separation of concerns. Multi-repos that have not worked well: again, opposites of the previous, including git submodules (please, just don't), code duplication, fragile dependencies where changing any repo meant all had to change.