By breaking your software into small open-source packages, you make the entire product easier to maintain—and significantly higher in quality.

Yegor256 Blog offers insights, opinions, and discussions on software development, engineering practices, and technology trends. Covering topics such as object-oriented programming, code simplicity, and software design principles, Yegor256 Blog provides resources for developers and tech enthusiasts. Developers can explore unconventional ideas, challenge conventional wisdom, and broaden their perspectives on software craftsmanship through Yegor's blog posts and essays.

Yegor's Blog

Breaking software into smaller repositories instead of using monolithic repos improves code quality through stricter style enforcement, deeper testing, more thorough code reviews, better documentation, faster release cycles, improved AI agent effectiveness, quicker onboarding, stronger code ownership, and easier open-source adoption. While companies like Google and Facebook favor monorepos for reduced integration overhead, smaller repositories enable teams to maintain higher quality standards across multiple dimensions of software development.

Small Repo, High Quality

The drawback is that small repos require high discipline to use.
If there isn’t a high degree of separation, what you end up with is a system that feels small, but in reality has lots of hidden dependencies. Better known as a big ball of mud architecture.
There is also a lot of overhead and costs associated with multi-repo. That may be fine, and something you are willing to pay if you can get the benefits of small, independent repos.
However to get the benefits there has to be strong separation. Microservices for example, have to be independently deployable. If the separation isn’t strong the result is a distributed monolitt.
It also depends on the size of the organization. If the team is small. 5 ish developers. There isn’t any benefit. Microservices is specifically designed to solve the problem og scaling a technology organization. It that case is ok to pay the extra costs that comes with splitting the codebase.
You can separate your code in a monorepo too btw.

I also have other philosophical reasons for preferring atomic repositories, but yeah, this article makes good points. 👍

One thing to note about this post is that microservices aren’t always the right solution. Smaller repositories are the least stressful, and the situation worsens as the number of repositories and the amount of code increase.

Good perspective. Smaller repositories can enforce clearer ownership, higher quality standards, and faster iteration, especially for teams that value autonomy. As with most architectural choices, the trade-offs between monorepos and multi-repo setups depend heavily on team size, tooling, and organizational maturity.