9th
In “On the Criteria To Be Used in Decomposing Systems into Modules” Parnas writes:
(…) the order in time in which processing is expected to take place should not be used in making the decomposition into modules.
(…) 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.
Those are statements from ‘72 but still applicable in today’s programming. In fact, a few years ago I’ve made a mistake of decomposition described by this paper. Pythoscope is divided into inspector and generator, two modules that correspond to two steps of execution of Pythoscope. In time the data module (called store.py) grown enormously, backing up other module’s needs. Execution time decomposition clearly wasn’t a good fit.
In retrospect, I should have kept a closer eye on data abstraction (implemented through functions, not classes, which is another lesson learned from SICP), so changing algorithms wouldn’t be so hard as it was in Pythoscope.
