Good software developers tend to be organizing freaks: everything goes in a tiny little box in its proper place. You know the saying “there’s no limit to how complicated things can get, on account of one thing always leading to another.” This is especially true in programming.
To combat this creeping complexity we strive for modularity and maintainability. A small module that encloses a specific business rule is easier for testing and allows for greater flexibility of reuse. When modules become too small however, the sheer act of tracking them, organizing their use, maintaining consistent versions, and finding where a business rule gets implemented interferes with your productivity.
Somewhat counter-intuitively smaller modules also need greater external documentation, mainly to track the nature of the parameters passed between them.
What’s the right size for a module then? And how many modules should a
system have? Although I like a module to be between a half and five printed pages it really depends upon two things: how many people are
maintaining the software and the density of the development language.
The fewer the number of developers the larger modules can be. Each of you is baking your own cake. So if it’s just the two of you maintaining a legacy billing system written in an old dialect of Basic (that gets about as complicated as a GOSUB and a CALL) then sure, go with the 5-page modules.
But if a half-dozen of you are planning to maintain ASP web pages in C# (with overloads and inheritance) then you’d better veer closer to the halfpage module size. In that case you’re not each baking a cake; you’re all contributing to building a car. You need to be able to swap in new replacement parts when the old ones wear thin. Every once in a while step back to review how you are developing the code: are you using appropriately sized modules?
