Fragmentation

> If the problem was decomposed based on ‘natural’ lines that tend away from dependencies, then the idea of treating stuff as fragments would work. But they don’t know what that means, so it doesn’t happen.

This is such a good line. Most dependencies I see in enterprise software fail miserably at this and that's why they think they need a monorepo.

I've found that people with substantial open source experience are often much better at figuring out what the 'natural' lines are because they tend to see the modules and libraries which they produce as final products. Their libraries are designed to be highly composable and cater to a broad range of use cases and systems.

The key is writing components that are generic and broadly compatible. You want to avoid putting business logic into your dependencies. Try to keep all the business logic at the highest level possible in your code.

It's very simple if you think about it; just imagine that you're a new developer on a large project, what would you want the code to look like? Most likely, you want to be able to understand what the system is doing by reading as few files as possible and you want the system's features to map to these top-level files in an obvious way.

Because when you're debugging a feature, the first thing you need to do is figure out where in the code that feature is implemented. If you can't come up with a simple answer to this, then your system is probably poorly implemented.

As with anything, it's in the middle ground that the best solution is often found. I'm working on a piece of software that's so unfragmented that one of the exe it produces, which by all accounts ought to be around 10MB, ends up being 110MB. Because it's not possible to detangle the mess.

At the same time, too much fragmentation will lead you to, indeed, have so many callbacks and other "controller" classes that you'll need a non-trivial amount refactoring anything you need to add a new feature, because the previously chosen lines of delimitation don't correspond to what the new feature needs.

Encapsulation vs decomposition is a recursive problem. It can happen at any complexity scale. The trick, I think, is to find the level between the two that works for your project. Can you decompose your project into small, independent, testable units? Can a single unit be tested in isolation from all the others? One person will tell you that's a fragmented system while another person will tell you that all your software components are nicely encapsulated. It depends on your perspective and your needs.

P.S. in any case, a robust interface specification is a prerequisite to good engineering.

I don't think encapsulation is the answer either. It leads to the same problems that the author mentions (which I think are real).

Brian Will has a very good video explaining this (timestamp is where he talks about encapsulation).

https://youtu.be/QM1iUe6IofM?t=1090