SPLASH '12 Workshop - What Drives Design?

Workshop final report

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

Workshop:  What Drives Design?
SPLASH 2012, Tucson AZ
Sunday October 21, 2012

The subject of this workshop is software design:

  • what kinds of design work do we do?
  • how do we work on our own, how do we communicate about designs to others?
  • how do we teach young professionals about design?

Some ideas about design are controversial:

  • the role of modeling in thinking about designs and writing design documentation
  • Test Driven Development

Some are less controversial, but are still hard to do:

  • teaching people about design using "group work" and complex projects to get hands-on experience
  • how to be innovative in the design process

For the busy software professional, design artifacts may come last:

  • I'm busy; I have a target date to deliver my code
  • no one is reading my design documents anyway
  • so maybe design is something we can't afford?

Three main questions explored:

  1. How to tell if a design is good or bad?
  2. What do we teach young practitioners about design?
  3. The role of collaboration and teamwork in design -- what are good tools and techniques for teams?

Question 1. Good design / bad design

Good designs need to "communicate" to others effectively:

  • yourself (to keep things organized)
  • other development team members
  • customer (to show you will deliver)
  • project manager (to make tactial decisions on staffing and resources)
  • executive managers (to understand what value will be delivered)

You might not share the same design view with all of these people

  • for customers, all developers need to tell a consistent story
  • for project manager, information about progress and risks

We need a multi-level design to meet all communication needs

  • in an agile project, communication within the team is important
  • also communication with other teams

Some standard techniques for evaluating designs:

  • Law of Demeter
  • SOLID (Bob Martin)
  • Design Patterns
  • code smells

Good design are:

  • expressive, coherent, understood, suited for use, testable, changeable, predictable, and habitable (Rebecca Wirfs-Brock)

We want to avoid:

  • rigidity
  • fragility (parts of the design fail)
  • immobility (hard to reuse parts of the design due to entanglements)

Rebecca Wirfs-Brock advocates:

  • don't limit yourself to just one xDD process -- blend some ideas from several methods depending on the circumstances

A warning about TDD: developers might get stuck at the lowest level of TDD -- need culture, community, and higher-level scenarios to get unstuck

What causes bad design?

Can UML drive bad design?

  • it depends
  • it is important to keep your models small and comprehensible: fit on one white board page
  • big models are hard to assess, hard to modify
    • in order to build and maintain a good model, it needs to be small enough that the team can "reason about it"
    • one proposed guideline for the size of a model -- it should fit on a single whiteboard
  • better to focus on the high level -- create a top layer that tells the design story
  • and create small submodels that zoom in on specific parts (possibly things like persistence, core engine, etc.)
  • [Discussion with Eduardo Guerra in the poster session:  he sets up a design brainstorming session with his students outdoors -- design teams of three or four students working at an easel outside of the building.  This is a good way to get them away from their computer-based tools and increase the direct collaboration between team members.]

We always need some test planning -- but in some systems, we need more.

Question 2. What do we teach to students and young professionals about design?

  • What we teach will affect their attitudes to teamwork, communication, documentation, and maintenance

Teach teamwork and collaboration at the same time as teaching design techniques

Participative design - less bureaucracy, more teamwork

Learning about design is a lifelong process, with different approaches for

  • students
  • new professionals
  • more senior staff (both people who stay technical or go into management)
  • everyone needs to learn more about new technologies to stay current

How do assign grades in a project-based course?

  • it can be done -- some have a complex rubrik
  • it may include instructor-team discussion about who contributed what
  • not just "everyone on the team gets the same grade"
  • the same ideas apply in industry

Consider using open source projects (github) as a place to get some design collaboration experience

What do we want to teach people about design?

  • Design is about organizing work - identification of blocks, packages, components - outline scenarios - maybe used advanced dynamic modeling concepts (state machines, table driven) - we continue to ask questions about how to improve the design - simplify, abstract, extend, increase reusability
  • Teach by example - show good designs, and talk about why they are good - Not just a "static design", but a "movie" of how the design started and evolved - Some books that talk about good designs: Beautiful Code and Programming Pearls (by Jon Bentley)
  • Teach Design Patterns (with examples) - reading group is a good approach in industry - look at the book Refactoring to Patterns (by Joshua Kerievsky) for practical ways to introduce patterns
  • Apprenticeship with a good designer -- a good way to get solid design experience

Question 3. Collaboration and teamwork -- what are good techniques and tools?

Some tools for both co-located and distributed work:

  • WebEx, VNC, screen sharing
  • IRC, Jabber, other chat applications

Tools for co-located teams

  • White board
  • Pair programming
  • Design presentation for the team
  • Cartoons and pictures to illustrate high-level concepts - don't make them too realistic - keep the discussion at one level down from the requirements and use cases
  • Other pair working (a group of 2-4 collaborating on design) - a cross-functional team with experts in DB, security, UX

Important tools for communication

  • effective listening
  • diversity training
  • CRC cards -- old technique, but still a really good to define scenarios as a group

Are there any xDD methods where collaboration is better?

  • more collaboration in RDD, DDD, BDD
  • much less collaboration in TDD (unless you really work hard to increase collaboration)
  • in CDD, collaboration is focused more narrowly on the contracts
  • in ATDD, collaboration is good if there is collaboration across the group (including testers) and collaboration with the customers

Collaborating is partially about persuading

  • not always rational -- see The Necessary Art of Persuasion (J. A. Conger, Harvard Business Review, 1998)

Will agile methods improve collaboration?

  • maybe -- cross-team design reviews or cross-team participation in Sprint Reviews can help spread knowledge


  • can be a spur for discussion (more informal modeling)
  • or they can be specification for what must be delivered (reduces the opportunity for collaboration)

Extra topics

* Is my design good?  I need to ask whether the design satisfies the needs of:
  • customers (the right features and behavior, delivered on time)
  • development team (current and future, to support integration, evolution, bug fixing)
  • individual designer (have I learned something that I might use in the future?)
  • stakeholders (managers and development sponsors -- they need information to manage risk, schedule, and people)

It is an overconstrained problem to meet the needs of these four groups. (We can't satisfy everyone 100%.)

* Innovation -> there is a balance between creativity and structure

  • sometimes creativity can *enhance* structure

* Learning from failure is important

  • we can "mine the gold" from project retrospectives or agile retrospectives
  • we should be documenting "failed or rejected design alternatives"
  • occasionally ask "why did we reject that?" -- something might be different today

* Which xDD method should I use?

  • it depends
  • no real answer, depends on context
  • do I need more collaboration? consider RDD, DDD, BDD
  • do we need to talk more with customers? consider the links between the software design and the business design

Enter supporting content here