I’d like to go with wider interpretation of Conway’s law[0], and think as if people organizations and code bases develop under similar laws of nature. Then I’d

I’d like to go with wider interpretation of Conway’s law[0], and think as if people organizations and code bases develop under similar laws of nature. Then I’d rephrase the theses: “Here are all sorts of ways to write good code with fewer helper classes and less boilerplate code”. “That sounds nice for a small code base but it would never work for a large code base”. I don’t have a proper synthesis for these, but I’d say that large code bases must be split into smaller ones, so that each sub-project is more focused and has better code quality. But also all those things matter only while the code is your product that makes you money. If you write the code as a contractor for sale (or you prepare a company for an IPO), you’re not incentivized to improve code quality, you just need to cram enough features in order to close the project and forget about it (or do absolute minimum to maintain it while your maintenance contract or vesting schedule lasts). [0] https://en.m.wikipedia.org/wiki/Conway%27s_law https://en.m.wikipedia.org/wiki/Conway%27s_law