Linda Rising

risingl@agcs.com

AG Communication Systems

Recently, I wrote a chapter for a CRC Handbook on Object Technology [1]. The topic of the chapter was patterns mining. In that chapter I shared my experience with patterns mining using the following techniques: Mining by Interviewing, Mining by Borrowing, Mining by Teaching Patterns Writing, Mining in Workshops, Mining Your Own Experience, Mining in Meetings, and Mining in Classes. One very productive technique and one I enjoy is: Mining in Workshops. In this paper, I will describe: (1) the approach, (2) the results, and (3) the challenges in convincing an organization to use this approach in pattern mining and suggestions for overcoming these challenges.

In April 1996, Jim McCarthy, author of The Dynamics of Software Development [2] paid a visit to our company. Jim was not familiar with patterns but his book contains a collection of guidelines that resemble patterns. He told the story of a problem-solving workshop technique used by management at Microsoft. Managers would gather around a conference table and someone would begin by describing a problem and asking for help in its solution. Someone would propose a solution, "We had that problem on Project W and we resolved it by doing X." Someone else would respond, "Yes, we also had that problem and we did Y." After a few proposals, someone would summarize, "What we're talking about is Z!" At that, notebooks would open and managers would start writing. What was being observed and captured was the essence, a high-level extraction, of the solution to the problem. They were capturing a pattern!

My fellow patterns miner, David DeLano [3], and I are always on the look-out for new pattern mining approaches. We thought we might try the workshop format. By happy coincidence, as we were debating this approach, we were also teaching a patterns writing course. A pattern written by Mike Sapcoe, a system tester, provided the opportunity we were seeking. Ray Fu, the coach for system test, was interested when we explained what we wanted to do and supported us.

The essence of the workshop technique we used is to collect the right people in a room for a day and encourage them to talk about recurring solutions to problems in a particular domain.We actually experimented with the pure Microsoft technique, that is, having people bring problems to the table but we found that the disucssion simply escalated into a giant whining session and no useful information was produced. We altered the approach slightly, asking for recurring solutions and the results were impressive. Focusing on solutions instead of problems gave participants the right mind set and the discussion was less heated and more productive.

The success of the workshop depends on having the right people, the ones with years of experience in the domain, willing to share their insights. You might wonder how anything can come out of a disparate collection of experts, each with his or her own set of experiences and view of the domain. Most of those who have followed the patterns activities know that a building architect, Christopher Alexander, has had envormous impact on the patterns movement. In his work, The Timeless Way of Building [4], he writes:

"Every person has a pattern language in his mind. ...Your pattern language is the sum total of your knowledge of how to build. The pattern language in your mind is slightly different from the language in the next person's mind; no two are exactly alike; yet many patterns, and fragments of pattern languages, are also shared."

This sharing or overlapping of patterns allows us, as patterns miners, who listen to the contributions of a collection of domain experts, to make sense of it all. David and I sat in a room with a dozen of our best system testers and typed furiously while the discussion raged around us. We were lucky to have the assistance of Greg Stymfal, a member of our patterns community with system test experience and effective facilitation skills. This role is critical in corralling a room full of old hands!

At the end of the day, David and I went back to our desks and spent the next few weeks trying to translate our notes into patterns. We then held several follow-on workshops to look at our fledgling patterns, improve them, and gather ideas for new ones. The attendance at subsequent workshops included some from the original group and some new contributors. In a couple of cases, new hires were included, not to contribute, but to learn more about system testing!

The result of this experience with workshops is a paper that will be published in the pattern series by Addison-Wesley [5]. It is also available on our web site [6].

Since the time of publication, the patterns have grown considerably and continue to grow. Patterns are living things that change as we learn more about the problem, the context, the solution. Some may completely outlive their usefulness as procedures and other technologies change. These patterns should be gracefully retired as new ones spring up to replace them. As Alexander has observed [4]:

"As people exchange ideas about the environment, and exchange patterns, the overall inventory of patterns in the pattern pool keeps changing. ...Of course, this evolution will never end."

We grow the system test patterns by repeating the workshop experience, each time with a new set of testers. We present the existing patterns and ask for feedback, again, typing energetically to keep up with the comments. Everyone agrees with the solutions in the patterns and many testers help us improve the patterns with new stories. We have also split some patterns into two or more smaller patterns and spawned new patterns. During this workshop process, the testers learn the existing patterns and we learn how to improve them. In this new training approach, the trainers and the trainees both learn. As Alexander has observed [4]:

"The fact is that we feel good in the presence of a pattern which resolves its forces. ...people who come from the same culture do to a remarkable extent agree about the way that different patterns make them feel."

Our goal is to have all system testers go through the system test patterns workshop experience. We will then teach the patterns to our coaches and the rest of the corporate development community. This should ensure a more uniform view of problems faced by system test and the solutions of our experienced system testers.

At this point, most of the system testers have participated in a workshop. Some have attended more than one. I presented an overview of some of the patterns to our vice-president's weekly staff meeting. Some of the system testers have told us that the system test pattern vocabulary has started to appear in project discussions. Even management knows the names of some of these patterns! No one has said that these patterns are not valuable. Our biggest disappointment is that we haven't been able to offer the course enough times to really attract developers who are not system testers.

Usually the company gurus, the people everyone recognizes as having the best domain understanding and the greatest knowledge of company history, are extremely busy people. Most developers are tied to a project, and when that project finished, they have a little breather between projects and a little time as the next project ramps up. Gurus are always tied to several projects. They are in constant demand. They never have a breather. Even though they recognize the need to transfer what they know to others, they often do not have the time for the interview and the subsequent review. Ralph Johnson once suggested [7] that we take these people off-site, away from interruptions, for a day or a week-end. This suggestion has been documented as one of a collection of patterns for introducing patterns into the workplace [8]. This solution has been used at our company but not for mining patterns.

The related problem with interviewing gurus is asking the right questions. Some we have used:

What would you share as a mentor?

What would be lost to the company if you left tomorrow?

What problems have you solved successfully on several projects?

What do you say repeatedly at project meetings that never gets documented?

Gurus are strong, extremely knowledgeable people and steering them toward useful information takes skillful interviewing techniques.

I remember being concerned that in these days of corporate downsizing that experienced developers would be reluctant to share information. In fact, the opposite is true. Everyone is anxious to share experience. No one seems to be afraid of becoming less valuable to the company. In fact, sharing successes makes these contributions visible, when, in many cases, that accomplishment would have been lost completely. The stories these people tell us are the most valuable part of the patterns. Roger Shank has written a fascinating book that helps explain this [9]. He states:

"People need to talk, to tell about what has happened to them, and they need to hear about what has happened to others, especially when the others are people they care about or who have had experiences relevant to the hearer's own life."

The stories are documented in the pattern rationale. Stories always draw readers in. They love to hear a personal account of what went wrong or what went right on an earlier release of a product. The people at my company have a tremendous respect for each other. I think that's why the patterns work has been so successful. Shank supports our observation:

"We can tell people abstract rules of thumb which we have derived from prior experiences, but it is very difficult for other people to learn from these. We have difficulty remembering such abstractions, but we can more easily remember a good story. Stories give life to past experience. Stories make the events in memory memorable to others and to ourselves. This is one reason why people like to tell stories."

I know after briefly talking with Steve Fraser at a conference in California, that a workshop technique can be useful for domain engineering. That was one reason for choosing this topic for my brief paper. The idea of bringing a small group of people together to produce a collection of patterns for system test or a domain analysis for a particular application, has powerful implications for better software engineering. If this presentaion is chosen for your workshop, I look forward to spending a day discussing this interesting topic!

1. Rising, L., "Patterns Mining," CRC Handbook of Object Technology, CRC

Press, Inc., Boca Raton, FL, to be published.

2. McCarthy, J. Dynamics of Software Development, Microsoft Press, Redmond,

WA, 1996.

3. DeLano, D. "Pattern Mining," to be published in Best Practices: A Patterns Handbook, SIGS Books, Inc., New York, NY.

4. Alexander, C.A. The Timeless Way of Building, Oxford University Press, New

York, NY, 1979.

5. DeLano, D. and Rising, L. "A Pattern Language for System Test," to be published in Pattern Languages of Program Design 3, Addison-Wesley

Publishing Co., Reading MA, 1997.

6. AGCS Patterns Home Page: http://www.agcs.com/patterns

7. Johnson, R., private conversation, July 1996.

8. OOPSLA '96. "Introducing patterns into the workplace," http://www.agcs.com/OOPSLA/intro.html

9. Shank, R. C. Tell Me A Story, Charles Scribner's Sons, New York, NY, 1990.

Copyright (c) 1997 AG Communication Systems