Bugs grow linearly when writing them, not after they are written. > divide a large codebase (in the case of superlinear bug growth). I do almost exactly that

Bugs grow linearly when writing them, not after they are written. > divide a large codebase (in the case of superlinear bug growth). I do almost exactly that when approaching a problematic system: refactor aspects of it as pure components or separate services in order to isolate behaviours from each other. Even just what you describe - breaking a large codebase into two smaller (working) ones - exposes an interface that can reveal failed intentions. It's just usually an incredible bitch to do, unless you initially refactor the parts to minimize internal state and the types of interactions the two parts have (ie - make them more 'pure'). Decidedly super linear, IME.