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:
- How to tell if a design is good or bad?
- What do we teach young practitioners about design?
- 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:
- 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:
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
- 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
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)
* 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