Parnas concludes the paper “On the criteria to be used in decomposing systems into modules” with the following paragraph.

We have tried to demonstrate by these examples that it is almost always incorrect to begin the decomposition of a system into modules on the basis of a flowchart. We propose instead that one begins with a list of difficult design decisions or design decisions which are likely to change. Each module is then designed to hide such a decision from the others. Since, in most cases, design decisions transcend time of execution, modules will not correspond to steps in the processing. To achieve an efficient implementation we must abandon the assumption that a module is one or more subroutines, and instead allow subroutines and programs to be assembled collections of code from various modules.

(The idea of decomposing a system based on its likely variations is also explored in Parnas’s later paper “On the design and development of program families”.)

Thirty years later, “The secret history of information hiding” describes how Parnas came to this understanding of modularity by observing a “napkin of doom”. You might find this latter account more informative and entertaining, especially if you don’t care for the technical details of an index production system.

If only as a straw-man example, pick out an actual occurrence in your field where people used or defined modularity. What do they use their notion of modularity for? Does their notion agree with Parnas’s? That is, would they admit something as a module that Parnas wouldn’t, or vice versa? How do Parnas’s engineering arguments carry over to your example—or not? Could Parnas have been discussing the “modularization”, “information hiding”, “efficiency”, “hierarchical structure”, and “flowchart” of cognition? Please share your thoughts on the class email list.