If you split it into little parts, and those parts have no sensible meaning on their own or no sensible interface and semantics -- then you're absolutely right.

If you split it into little parts, and those parts have no sensible meaning on their own or no sensible interface and semantics -- then you're absolutely right. Testing such parts will be difficult, too, because of this. But if instead of a monolith, you have a set of components with well defined interfaces that have simple semantics (that do not leak abstractions) -- whether or not these parts are re-usable in other contexts -- then you almost automatically have higher quality software: * Easier to test means it will likely be better tested * Well-defined interface and abstraction and a small implementation means that reviewing/correctness becomes easy. You only need to understand a small component to review it. "Obviously no bugs" rather than "no obvious bugs" * Easier to split the work across developers * Easier to comprehend the whole as a collection of its parts The total number of lines of code, or even the total complexity may increase relatively to a monolithic design. But correctness becomes so much easier. You mention refactoring, too, and IME, refactoring can be both easier or more difficult, depending on whether it is within a single small component or across multiple ones. If you add architectural/design changes -- then it is night and day. A monolith will likely have to be rewritten to make an architectural change reliably. A set of components can easily be split, for example, so that a few components are moved to run on a different system with a network protocol between them.