ModularityMistake

Context : OnModularity

Any system can be thought of as decomposed into modules. HerbertSimon thinks there are an alternative number of natural or good ways of decomposing a system into modules. Typically modules have strong internal connections (cohesion) but weaker and stereotypical external connections (coupling)

When you design or maintain a system, you are likely to conceive of it, and approach it as a set of modules. However if you draw the boundaries is the wrong place, you are making a modularity mistake

Examples :

• TheCityAsInformationSystem (for modularity mistakes in urbanism)

• SpaceAndModularizingWebPages / DecompositionByLanguageIsProbablyAModularityMistake (decomposing web-sites by space vs by language-type)

• OutSourcingAsAModularityMistake

• LearningNetworks

• LocalFineGrainRemoteCoarseGrained

• Wild thought. Could some economies suffer because the notion of property draws the boundaries around property in the wrong place? PropertyModules

• Getting the wrong granularity is a kind of modularity mistake. But let's give it it's own page GranularityMistake

What's wrong with a modularity mistake?

Makes communication between the parts difficult / expensive as often module boundaries are harder to cross than internal communication. In the paper linked from HighDensityLiving, urban modularity mistakes translate into higher transport cost and pollution.

See also :

• SystemInflowMistakes

• OnModularity

• SubsumptionArchitecture (for a challange to traditional functional decomposition in robot design)