The nearly 100 slides that Rebecca used to convey her message are available to you through the OTUG.ORG website so I'll try not to repeat too many of her statements but rather summarize the talk enough to encourage you to view those slides. The strongest point that I took from the lecture was one of the first things she said and that was that your models should have a specific purpose and that your documentation should add value.
Rebecca has seen a healthy skepticism in the industry and that some people are put off by glib agile statements. There is even a false interpretation that we don't do design anymore in software development and we don't document anymore and that is what agile represents to them. Not true. Agile designers and their managers need to respond to changing situations and steadily work on their design. Rebecca doesn't enjoy writing stuff that no one reads and so the goal is to cut out inefficiency, not to cut corners. Rebecca is a picture person and points out that models should add value and tell you something when examining the code will not. Agility is not a recipe that can be blindly followed. A process that works for one project won't necessarily work for another. An example might be that eXtreme programming isn't as good a fit when the team is all remote and therefore you have to employ the right strategy for your situation.
The lecture was structured to talk about the different skills a designer must focus upon for seeing the problem, then shaping a solution, and then describing the design to others. To help see the essence of a design problem, Rebecca draws on some insights from Dr. Betty Edwards, a world-renowned educator in the field of art. Edwards is the author of the best selling non-fiction books Drawing on the Right Side of the Brain and Drawing on the Artist Within. Dr. Edwards feels that given proper instruction, the basic perceptual skills of drawing can be taught and can be learned in a short amount of time and that talent only seemed rare and extraordinary. Wirfs-Brock says there may be a connection to the perceptual skills necessary for realistic drawing and the skills a designer needs to use to think abstractly in developing a well-factored object design based on object roles. An agile designer needs to think abstractly and draw objects quickly to "feel what's in the clay". An agile designer will know when they've drawn a good design as well as know when it is still clunky.
A stereotype is a purposeful oversimplification. Even though the word can carry a negative connotation in English, we can use the concept to help us focus on an object's responsibilities. Rebecca's Smalltalk roots tend to make her personify objects and she reminds us that an object doesn't just hold information but also deals with what it has. In UML stereotypes are tags that can be added to objects to classify them in various ways. She mentions as an aside that it was a small victory for her that the newer UML version will finally allow a class to have more than one stereotype. The essence of a stereotype is that it suggests certain outline responsibilities for a class. (shown between guillemots "« »" in a diagram). Rebecca cited the work of Peter Coad and Stephen Palmer to use color. Color modeling uses standard UML extension mechanisms to indicate the four archetypes: moment-interval, role, description, and party/place/thing. Coad says color reaches out and grabs you. Rebecca says an agile designer will pick up any trick that works.
To shape reasonable solutions to design problems, Rebecca Wirfs-Brock discussed the traits of an agile designer to not fudge on design complexity. Design patterns are not to be used just because they are described in a book. While you use patterns as archetypes, you must explore alternatives. For her real world example, she discussed a system titled Speak for Me which was to be designed to enable a severely disabled user to communicate via the blinking of an eye. She walked through some iterations in her design where refactoring was applied. She described when things don't go according to plan, the agile designer readjusts her thinking and tries again. After a break in the lecture for some dessert, Rebecca discussed carving your software into regions where "trusted communications" occur. There can be a simplified behavior for objects where you can assume trust while objects at the edges of the trust regions take on added responsibilities.
When it comes to describing design choices to others, the agile designer must use different tools to communicate and express the message to answer the questions as to why we are doing it this way. You have to remember that not everyone reads code. Also a standard diagram is not necessarily a natural way to best describe a design. Sequence diagrams, bless their heart, have merit but they don't show side effects well or special areas. Although one can use UML as a second language to their advantage, you should also consider other forms. Use words, pseudo-code, BNF grammar, decision tables, state tables or pictures to emphasize certain features. Rebecca used the example of a bubble sort algorithm to display the various methods for communication that might be better than a sequence diagram. The idea is that text should explain it coupled with a visual example. Remember that you are doing this so someone else will understand. Your job is to communicate and you need to find a way that works. But not every story is worth telling in detail. Don't feel compelled to use every UML feature and use caution so that a case tool doesn't lead you to overtelling. Present your design so that important things get emphasized. You want to show what the design is, what parts are adaptable and how to adapt. Add notes to show recipes to adapt. Stick with your story, stick to one point of view, and consider your audience. And don't forget to use common sense to show the gist of your design.
The concluding section of the lecture was about design rhythms. Design can be somewhat predictive. You can sometimes estimate the effort but design problems vary. Rebecca places design problems into three camps and suggests that each type warrants a different approach and has a different rhythm in solving it. There are core design problems that include the fundamental aspects to your design's success. There are revealing design problems that require iteration and can completely shift your view. And there are the rest, which require work but not nearly as much inspiration. In describing revealing problems, Rebecca mentioned a recent article written by a Twin City local practitioner, Mary Poppendieck, entitled "Wicked Problems" (in May 2002 Software Development Magazine) that summarized the type. What distinguishes revealing problems from core problems is their degree of difficulty and the element of surprise, discovery and invention. They can cause you to discard what you had assumed to be a fundamental truth about your design and replace it with something more complex. Such problems are really hard and they are tamed rather than solved.
For more information, view the presentation slides available on OTUG.ORG web site and related articles on Rebecca's site at http://www.wirfs-brock.com/. This information is covered in depth in the new book, Object Design: Roles, Responsibilities, and Collaborations by Rebecca Wirfs-Brock, Alan McKean.
This was another terrific lecture in the Distinguished Lecture Series that OTUG has delivered. Rebecca made reference to other luminaries in the field that have also been on our stage. There has been a lot of hype about agile in the press and advertising and the word is fast becoming too commonplace. To keep focus on what we mean by it in our industry, remember the values presented in the agile manifesto.
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: