Modularity

Writing large programs is incomparably more difficult than writing small programs. The novice who has learned enough to write a 1,000 line program is inclined to believe that writing a 10,000 or 100,000 line program requires only the same techniques, done ten or a hundred times longer.

The fundamental problems are that

• Left to themselves, all parts of a program tend to interact, and it is keeping track of, controlling, and changing these interactions which constitutes the bulk of the work in a large program. Given free interaction between all parts, a 10,000 line program will be 100 times more work than a 1,000 line program, and a 100,000 line program will be 10,000 times more work than a 1,000 line program.
• Humans have a very limited ability to keep lots of different things in mind at one time, especially when dealing with difficult problems, especially over long periods of time.

Modularity is the programmer's first line of defense against both of the above problems: One breaks the program up into small modules, and works very hard indeed to drastically limit the interaction of each module with the others to a very narrow interface. Ideally, this results in it being possible to completely understand a given module without needing to understand the rest of the program, and also makes it possible to safely, reliably modify one module without needing to understand or modify any other parts of the program.

Programs are not naturally modular, nor is there any simple recipe for imposing modularity on a program: Finding a good way to modularize a given program is a fundamentally creative process, and discovering a pleasing way of untangling a recalcitrant knot of code into cleanly separated modules is one of the more satisfying moments in the programming process.

Modularity does not come for free, either: Imposing modularity on a program can result in slower code, code redundancy or obscurity. Real world engineering involves real-world trade-offs like that: There are no magic wands that let one achieve all one's design goals for free. That is what makes great engineering a creative art, and that is what makes it so satisfying to find unexpected solution that achieves almost everything one had hoped.

("Object-oriented programming," to the extent that the phrase still means anything at all, is a particular bag of tricks for imposing modularity on a program, centering on the idea of factoring the program state into classes of similar objects, and then segrating into one module all code directly accessing the contents of a particular class. It frequently works very well, but certainly isn't the only way to modularize, nor always the best, nor even always applicable. For example, if your program has very little data, or only one class of data, it is of little if any help.)

Go to the first, previous, next, last section, table of contents.