What exactly is the problem with a "massive monolith in a monorepo"? Having it all together is perfect for code re-use and testability. It's also very easy to

What exactly is the problem with a "massive monolith in a monorepo"? Having it all together is perfect for code re-use and testability. It's also very easy to know if you broke the bigger picture while working on a subsystem of the monolith because the test-suite will tell you. In my humble opinion, monoliths are unpopular because not much thought went into the original design of the code and as a consequence there are large chunks of technical debt interfering with everybody's work. It certainly doesn't help that many popular frameworks don't give you the design architecture to grow big apps. But the good news is that if you don't split your teams, you also have more engineers on hand to refactor the codebase to be more manageable.