I'm not sure why monorepos are in the list. Care to elaborate?
I've worked on projects that used a single repository for all the code written by different departments and projects where the same department could have multiple repositories. The later added insane amount of busy work, inordinate amount of errors, difficulty to investigate failures, excessive use of resources to house various permutations of systems created at different times with different combinations of components. The day-to-day in such projects could be described by developers waiting for the infra people to sort out the morning problems which mysteriously broke everything all at once so that no progress can be made.
This was in stark contrast to companies working on a single repository, where days when nothing worked would happen maybe once or twice a year.
I also lived through transitions from multiple repositories to a single repository and the other way around. In operational terms, I've never seen any beneficial effects of splitting a repository. Not in the short, nor in the long term. Complexity always went up, productivity went down, general satisfaction with project infrastructure would also go down with such a change. Department would start attacking and blaming the infra people for creating obstacles to their progress (while never explicitly mentioning the split repository because, usually that was a decision made by the same people complaining).
Oh, yeah, all of those issues of enforcing transitive dependencies that need busy work to update, fluid APIs that make all the code around it break, lack of semantic boundaries that make it hard to decide if a problem is local, inter-component interference so that you have to select them perfectly well...
All of those are enabled by monorepos. And once people learn to do them, they seem to want to apply everywhere.
I've worked on projects that used a single repository for all the code written by different departments and projects where the same department could have multiple repositories. The later added insane amount of busy work, inordinate amount of errors, difficulty to investigate failures, excessive use of resources to house various permutations of systems created at different times with different combinations of components. The day-to-day in such projects could be described by developers waiting for the infra people to sort out the morning problems which mysteriously broke everything all at once so that no progress can be made.
This was in stark contrast to companies working on a single repository, where days when nothing worked would happen maybe once or twice a year.
I also lived through transitions from multiple repositories to a single repository and the other way around. In operational terms, I've never seen any beneficial effects of splitting a repository. Not in the short, nor in the long term. Complexity always went up, productivity went down, general satisfaction with project infrastructure would also go down with such a change. Department would start attacking and blaming the infra people for creating obstacles to their progress (while never explicitly mentioning the split repository because, usually that was a decision made by the same people complaining).