Design Rules: The Power of Modularity

1. Design Rules: The Power of Modularity Carliss Y. Baldwin & Kim B. Clark Elucidated with examples from the “common” program and asides about Parnas. Bill Griswold

2. The Modularity Conundrum • Powerful systems are built of many elements • Power comes from elements’ interplay • This interplay results in essential interdependences and reduces ability to • reuse element w/o others • change element w/o changing others A B Edges mean “knows about”

3. Common’s Design Structure Authors observe that these dependences and their grouping into modules are derived through experience with previous instances of the system. SE design methods are meant to bootstrap this process. count words impactstop words

4. Design Rules D. R. A’ B’ • Idea: have components depend on design parameters guaranteed not to change, called Design Rules • Design rule may be a convention, interface, representation, programming language, etc. • Design rules are the global, unhidden assumptions; they are the architecture • Chosen properly, elements depend on design rules rather than on each other, becoming true modules

5. Common’s Modularized DSM

6. Visible Modules Hidden Modules Common’s Design Hierarchy Icon Strings & Integers Top IF “Common” Interfaces Words Parse Input Top Top Words Format Output Main/Files

7. The Modular Operators • Modular operators restructure a design, presumably into a more modular form • inversion: lift local decision to visible module • independence via duplication --> design rule • substitution: replace one module impl w/ improved • classic Parnas motivation for modularity • split: break a module into two sub-modules • augmentation: add a new module to system • also exclusion: remove module from system • port: move module to another system • generalize and build system-specific adapters “Top” created by all except exlcusion!

8. The Value of Modularity • Modularity not only accommodates change • It encourages innovation by decentralizing decision making on hidden modules • Technically, it creates the option for third parties to innovate on a module • Parties compete to create a better module • A few “experiments” likely to create superior module whose value to users exceeds cost of experiments; downside minimal because can keep old • Cluster of innovators emerge around architecture, resulting in new industry

9. The Value of Splitting • Where j is number of modules: Vj = S0 + i E(X+i) • under normal distribution: E(X+i) = .3989(N/j)1/2 • Collect terms, set S0 to 0: Vj = j1/2 V1 • A system of 25 modules likely has 5 times the value of a monolithic system

10. The Value of Substitution • Where k is number of “experiments”: Vk = Q(k) V1 • Assuming a normal distribution: Q(k) = kz[N(z)]k-1n(z)dz • “Simplifying”, we get: Vk = ck1/2 V1 • Combining with splitting: Vj,k = cj1/2 k1/2 V1,1 Computing the Net Option Value of a module requires incorporating the costs of experimentation and picking the best module. Cost effectiveness depends on holding right number of experiments and on local module tests (e.g., size, speed, cost of module) as opposed to system tests.

11. main next-word top-words output-entry parse words mgmt top count Icon Input Output Common’s Extension Hierarchy Extension hierarchy reveals what augmentations and exclusions will be affordable files strings integers