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?

• misuse of tools/techniques
• misuse of metrics
• for example, there are some contexts where following some code smells or design principles will make a design more artificial
• removing duplication too aggressively -- makes it more difficult to follow the structure or scenarios
• introducing "mock objects" sometimes covers over the fact that you really need these objects in your problem domain (see Arlo Balshee's comments:
  • http://arlobelshee.com/essay/decoupled-design
  • http://arlobelshee.com/essay/how-i-learned-to-stop-worrying-and-love-the-mock
  • http://arlobelshee.com/post/mock-free-example-part-1-project-intro)

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

Models

• 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

• 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