I got pulled back to the book A Perfect Mess after reading a thread from Ginger Bill on code structure. His point is sharp: many teams say they want to organize code, but what they build is a taxonomy. They produce folders, layers, and patterns that look neat, then call that quality.
"Most people who say they want to organize their code actually mean they want to taxonomize their code."
Source: Ginger Bill
The core idea in A Perfect Mess is that a measure of disorder can save time, lower overhead, and map better to real work. Software has the same pattern. A program exists to solve a task for users and the machine, not to satisfy a model from a slide. If a small tool has clear data flow in one file, split layers and factory chains can make it worse even if the code looks "clean." The key test is simple: can a developer see what enters the system, what changes, and what leaves it. If yes, that is organization. Past that point, much structure becomes ceremony.
I do not reject structure. I reject structure as dogma. Good code comes from fit with the task, sound names, clear data movement, and sane tradeoffs on cost, speed, and change. A codebase should match the problem at hand. If that means tight modules, do that. If that means a flat layout, do that. The goal is not purity. The goal is a system that works, can change, and can stay clear under pressure.