Creating real design options through modularity

Recently I finished reading Design Rules, Vol. 1: The Power of Modularity. While I was less struck by this book than I was after reading Small Pieces Loosely Joined, I still picked up several points I hope to incorporate into my thought and application of design as a software architect.

  • An understanding of the forces driving change is crucial to comprehending the opportunities and the risk that change creates.
  • The first person that comes to mind as a practitioner of the previous statement is Pat Helland. What struck me… (read on)
  • Design is the process of inventing objects [or evolving artifacts, including intangibles like rules] that perform specific functions.
  • When applied faithfully, modularity greatly reduces the costs of experimenting with new designs.
  • Experimentation yields both new opportunities and new competition.
  • Chapter five of this book covered the complete set of modular operators as follows: splitting, substituting, augmenting, excluding, inverting and porting.
  • The design structure of an artifact and the task structure of the design process are isomorphic.
  • With respect to design, structure affects tasks deeply and unavoidably
  • Every hierarchical relationship and interdependency in the creation of a design requires a corresponding connection among tasks.
  • Human task structures have a fractal property.
  • Human beings are capable of visualizing new artifacts in an imaginative domain, and then acting purposefully to bring those artifacts into existence in the real world. Axiom: Designers see and seek value in new designs. Aside (bias beware): Personal value vs. market value ./li>
  • Imposing a design rule when one is ignorant of the true underlying interdependencies can lead to design failure. Or, as I’m known to say, Know what you leverage!
  • Modularity increases the range of manageable complexity.
  • Modularity allows different parts of a large design to be worked on concurrently.
  • Modularity accommodates uncertainty.
  • A modular design is a portfolio of options. Modularity creates real design options.
  • The value inherent in a modular design is potentially dangerous to its creators. Control in the system (and decision making in the organization) becomes decentralized; no one has to grant permission for experimentation to occur. In fact, such experiments can take place unawares. Taken to an extreme, system architects and integrators can modularize themselves out of existence.
  • However, as dangerous as this reality might be to some, the alternative is far worse in my view: Dominant Designs [that lead to], Frozen Organizations [that result in], and Complexity Catastrophes.
  • Does efficiency in software production necessarily require rigidity and lack of flexibility? What does this say about CMM, ISO-9000 and the like?
  • The driving force behind a quest for modularity is always a desire to achieve the right balance between fruitful uncertainty and paralyzing complexity.
  • Modularity is about abstraction, information hiding and interfaces.
  • There are two kinds of information hiding: visible and hidden.
  • Visible design choices are relatively irreversible; hidden design choices are reversible.
  • Visible design parameters == design rules

Aside: During part of my reading of this text, I saw a Citigroup TV ad, which showed a kid being swung by his dad while showing: Overtime pays more. <pause> Because of what you’re missing. Isn’t that the truth (and I don’t even receive OT)!

Update 12/1/2008: For more of my book reviews and to see what else is in my book library (i.e. just the business-related or software-related non-fiction therein), please visit my Books page.