Thread by @wycats

When you're writing software, sometimes you find that it's useful to extract some common functionality into an abstraction.

That can happen because:

- there's more than one consumer of a common chunk of code
- the ppl working on a chunk of code are very different from those who work on the code it's being extracted from
- the extracted code has a diff domain from the code it's being extracted from

Extraction works better when:

- the code takes well-described inputs and turns them into outputs (it's pure)
- the extracted code is changing much more slowly than the code it's being extracted from
- the ppl working on the code are willing to commit to a notion of stability

On the other hand, "premature extraction" is a common disease. It happens when people imagine a hypothetical abstraction boundary in their heads and try to will it into existence.

The tell-tale sign of premature extraction is: lots of changes to the application that the library came from ALSO require updating the library. Even if it happens 5% of the time, that's way too much.

A good extraction is "fire and forget" -- almost no changes to the application require changes to the library.

Nobody really disagrees with the idea that extraction can be useful. It allows code to evolve separately, and for library authors to make changes that can be absorbed by their application consumers at their own pace.

This is how we get popular libraries and frameworks.

On the other hand, tons of people have experienced the disease of premature extraction. It's fucking everywhere.

I've seen people build multiple packages as part of a new small project before they've even gotten anything working, only to spend the next few months shadowboxing their imaginary abstraction boundaries. I've been tempted to do it myself from time to time.

So it's no surprise that the siren song of monorepos is seductive.

"To hell with all that premature extraction! It's all pointy-headed nonsense! Real developers ship, and we'll never ship if we have to deal with all this pointless overhead!"

And to a large respect, that perspective is right. There is, indeed, far too much time wasted dealing with overhead introduced by theorizing that's not grounded in any kind of reality.

But banning even the *prospect* of extraction and separate versioning, as the monorepo philosophy does, is heavy-handed and throws away an incredibly important tool in the software engineering arsenal.

It also makes a big difference whether your tooling tries to support a hybrid model. Cargo (Rust's package manager), for example, both supports small libraries *and* large repositories that have multiple packages in them. It's possible to mix-and-match, and that happens a lot!

And there's a nice smooth process of extraction:

1. extract your code into a module
2. extract your module into a same-repo package
3. extract your package into its own repository

Each of these steps gains advantages from decoupling, but commits to stability more.

The final step, extracting a package into its own repository, is almost entirely about the *community* around the package -- the package has enough of its own contributors that sharing an issue tracker and CI tooling is causing more harm than help.

But critically, extracting a package into its own repository doesn't affect the usage pattern of consumers. They depend on the named crate, same as always. The tooling enables a transition along the "decoupling" spectrum to match the empirical cost-benefit tradeoff.

Yarn workspace are also an enabler of this kind of transitional workflow, and the existence of Yarn workspaces really did change how people think about the process of code extraction.

Rather than encouraging coupling, workspaces encourage an extraction into language-level packages earlier: at the point where isolation and stability is appropriate for the code, rather than at the point where the contributors benefit for separating the history and issue tracker.

Bottom line: there's nothing wrong with sticking a bunch of packages in one repository, but the "monorepo" worldview is far more fundamentalist than that. It suggests that, for a single company, the *only* viable way to do software is to stick *everything* in one repository.

In reality, whether to break things up, and how to structure the code you broke out is an on-the-ground tradeoff that depends a lot on practical details.

Even in a universe with perfectly frictionless tooling, there would still be *tons* of examples of premature extraction.

Ultimately what we need as software developers is tooling that enables us to do the kinds of extractions that make sense, and the fortitude and culture to resist extractions that do not.

Monorepos tell us that the answer is "No. Never." We all know that isn't right.