6.8.2 Modularity measures

What this heading covers

Modularity is structural and can be measured from code and dependency data. The useful measures are about boundaries: dependencies across a boundary, cycles, the size of the public surface, the number of modules that must change together. A high module count is not modularity. The measure should be tied to the intended architecture, because a product can be modular in a way nobody planned and still be hard to change.

Record position: family 27 of 40 in clause 6, under 6.8 Maintainability, which carries 5 families. It is one of the 40 families a programme has to map its measures to, and its elements are listed below. The heading is 6.8.2 in the public contents; the text behind it is not public.

How a measure for this family is built

Count the dependencies that cross an intended boundary as the numerator, over the dependencies examined or per module. Report cycles and the number of modules changed per feature as companion measures. Record the boundary definition, because it is the population.

What to put in place before publication

1. Write the intended boundary map before measuring.
2. Report cross-boundary dependencies, not only a module count.

Evidence to keep

Two questions to ask

• What is the intended module boundary, and who agreed it?
• How many dependencies cross it, and how many cycles are there?

Where teams usually fall short

• A module count presented as modularity, with no boundary in sight.

What the number cannot tell you

It cannot tell you whether the boundary was the right one. A clean dependency graph around a poor architecture measures the wrong design.

What happens next

Reusability is the family that asks whether a module can be used beyond its first context.