Code is basically a dependency graph. Each piece of code depends on a number of other pieces of code. (Dead code is an isolated island in this dependency grap

Code is basically a dependency graph. Each piece of code depends on a number of other pieces of code. (Dead code is an isolated island in this dependency graph.) You want two things out of that graph: less nodes, because less code is simpler, better, cheaper. And less edges, because understanding, modifying, or troubleshooting a piece of code requires knowing about its dependencies (hopefully, only the direct ones). When the unit of organisation is the function, you kinda state that each function is a node, and the call graph are part of the edges (the call graph would cover everything in a purely functional settings, but side effect produces implicit dependencies). Trouble is, in any significant system, you're gonna have a lot of nodes and edges. How to make sense of that? That's why we have module. When you look at your dependency graph, you will most certainly note that parts of your graph are denser than others. Those clusters are the natural modules. If you formalise that, and draw module boundaries around those clusters, you can now have a two-level view: inside a module, you have a small dependency graph, with a few outbound edges. Outside, you can visualise a coarser graph of module dependencies. Again, fewer nodes and edges, because you have grouped them. Now the real benefits of module is, once you start drawing boundaries, you have an incentive to make small interfaces, to minimise inter-module dependencies. Additionally, visualising the module dependency graph directly helps you spot spooky dependencies that probably shouldn't be there. You can then cut some dependencies out, simplifying your graph in the process. Without modules, I don't see how you would manage this kind of scale. Oh and by the way, some monstrosities are so big that they effectively requires a third level. But I've never worked on such beasts.