SPLASH '12 Workshop - What Drives Design?

Summary of Rebecca Wirfs-Brock talk: What Drives Design?

Home | Workshop final report | Summary of Rebecca Wirfs-Brock talk: What Drives Design?

Summary of Rebecca Wirfs-Brock talk at OOPSLA 2008

The video of the original talk is available online at the InfoQ website:
Rebecca Wirfs-Brock delivered an invited talk at OOPSLA 2008.  The talk had two main threads.  First, Rebecca presented some of the concepts in her own "driven" methodology, Responsibility Driven Design (RDD).  Second, Rebecca presented a comparison of several different "driven" approaches to software design and development - development driven by features (FDD), unit tests (TDD), behavior (BDD), contracts (CDD), models (MDD), agile models (AMDD), and domains (DDD).
Part 1: Overview of RDD
In the initial section of the presentation, Rebecca highlighted several important characteristics of Responsibility Driven Design:
1. RDD was an attempt by Smalltalk developers to move away from data-centric design planning -- moving instead in the direction using the list of behaviors or member functions to define encapsulated classes.    The biggest drawback of designing data-centric encapsulations (where classes focus first on data structures and data relationships) is that the implementation details start to drive the design.
2. Using CRC cards to do the initial design planning has been a good way to get the designers to give up global knowledge of control.  Each class or object has the local knowledge to accomplish its part of a task.  This approach reduces the number of gratuitous global variables and unnecessary pointers.  The approach also attempts to make each class cleaner and simpler, so a class implementation is not inappropriately reliant on the knowledge of the implementation of other objects.
3. The CRC brainstorming process creates a set of "candidates" -- which might sometimes be individual classes or might instead be implemented as a set of classes.  If we think of our objects at a higher level than just a class declaration in our favorite language, we will defer some of the details of the design until later.  This gives us time to let the detailed design and implementation unfold over time.
4. The book Object Design (2002) by Rebecca Wirfs-Brock and Alan McKean introduces the concept of "role stereotypes", which is a useful way to think about the primary responsibilities of each class.  The book also presents the idea of "control style" (centralized, delegated, and dispersed).
Part 2: Other xDD approaches
Here are some insights from the discussion of other "driven" design approaches:
1. Some of the design approaches have a faster or slower "rhythm".
  • For example, TDD has a fast rhythm, because an individual developer (or a pair of developers) works "story by story" in planning the design and "test by test" in the process of filling in the implementation details.
  • But in FDD, the design rhythm is "feature by feature" -- a small team works together to build or extend a design model, then write code and inspect code that implements the updated model.
  • AMDD (Agile Model-Driven Development from Scott Ambler) works in small steps -- alternating between the process of "modeling to understand" and "coding".
2. BDD, DDD, and CDD focus on different key artifacts.
  • BDD can be thought of as a subtle variation of TDD.  The core artifacts are the "behavior specifications", which are a kind of functional test.
  • DDD is focused on creating an object model where the names of the objects and operations are drawn from the vocabulary of domain experts.
  • CDD (contract-driven) focuses on formal specifications of the behavior of individual methods (input values, output values, preconditions, postconditions, and invariants)
3. Is it a good idea to "mix" practices and concepts from multiple xDD methods?  Rebecca posed this notion of mixing CDD and TDD in an online discussion forum and received three different reactions:
  • It isn't too bad, because the practices seem to be complementary.
  • It isn't good at all, and it is better to focus on getting one practice right.
  • It is heresy: you just dilute one practice by mixing it with another.

Rebecca thinks mixing practices is a good thing:  it is short-sighted to follow one approach strictly.  It is better to blend design techniques to help create designs that are expressive, understood, hang together, are usable and testable, and support design evolution and change.

4. Rebecca proposes some properties of good design that are drawn from the "15 properties of things that have life" in Christopher Alexander's book The Nature of Order:
  • "Levels of scale" -- Designers must consider different levels of scale when they evaluate the goodness of their design choices -- conceptual level (responsibilities), specification level (class interfaces, method signatures), implementation level (code, data, schemas).
  • "Strong centers" are essential to a good design -- and each of the "driven" design can contribute to this property.  For example, CDD has contracts that are specified outside of the method implementation, and the contracts can make the implementation simpler and better focused.  The "design centers" are also strengthened by having well-defined interfaces -- a practice that is supported by many of the xDD approaches.
  • "Local Symmetries" is a property that creates coherence in a design -- and most of the xDD methods support the realization of meaningful symmetry, not just blindly defining "setters" corresponding to each "getter".  The important design symmemtries are use of a common design language, consistent naming schemes, and consistent level of code detail.
  • "Deep Interlock and Ambiguity" is a subtle property -- most software designs need to support change, and that means the interactions between software components will change.  When we build our systems, we don't just click together a fixed set of standard components.  Our design techniques need to deal with dynamic contractual specifications.  Our design techniques will have to ensure that the  collaborations in our design remain valid as the design evolves.

Rebecca's conclusions:  Many different design approaches are useful and some of the approaches can be blended successfully.  The goal of good design is to build "livable" or "habitable" software (software that other developers enjoy working with).  It isn't so good to be compulsive ("driven in a bad sense") and to blindly follow one approach.  We need to consider using "the right tool for the job" if we want to build sustainable software.

Notes for the "What Drives Design" workshop at SPLASH 2012