OOPSLA'96 Panel Proposal #243
The key to making object technology work isn't technology. So what is it? This panel will cover a lot of the "soft" issues about dealing with people and teams. It's partly about managing software development, and mostly about doing it.
The panel will start with short position statements from each panelist. A number of questions (probably four), announced to the panelists in advance, will be discussed in turn by each panelist. This will take roughly half the time allotted. The remaining time will be spent answering audience questions, and allowing brief comments from the audience. The moderator will either take questions from audience members at fixed microphones, or will roam through the audience with a wireless microphone. The panel will conclude with brief closing remarks by the panelists.
To keep the panel and (especially!) the participating audience members from dragging, everything will be timed. Proposed time limits:
Time not used will not accumulate in any way (except for general use by the panel, favoring more audience participation). The moderator will use cards to indicate when thirty seconds, five seconds, and no time remains. The moderator will enforce all time limits strictly. Technical means to enforce these limits will be considered, but will not be necessary.
As at prior OOPSLA panels, panelists will be provided with green, yellow, and red cards. These cards will be used to provide non-verbal (and non-interrupting) feedback on what panelist and audience members are saying.
All of these combinations have been observed at other OOPSLA panels, and seem to work well.
The moderator suggests, but will not insist, the entire panel take place without slides or viewgraphs.
Ward is well known for his contributions to the developing practice of object-oriented programming. Ward created the CRC design method which helps programming teams find the objects that make the foundations for their programs. Ward has written on CRC and related topics in JOOP, OOPSLA and HOOPLA publications.
It is my position that small teams using an evolutionary development method in a pure object-oriented environment have the best chance of walking this tightrope. Each one of these factors, team, method and environment, can be adjusted and studied in isolation. However, when we consider the whole of the software development system we find debatable decisions for one factor can create surprising efficiencies for another. Using the terminology of patterns we would say that competitive forces, when resolved, expose unique patterns of lesser forces, which have solutions which might not have occurred in isolation. I have assembled a network of forty patterns of competitive development and studied the interactions between them. Competitive developers will find the particular patterns useful while organizational theorists might benefit most from adopting the pattern form.
Maybe the problem isn't the technology: OT has been around for quite some time, and there are real benefits associated with it. And maybe it isn't the developers: most developers want to do a good job, building the best system they can. And maybe it isn't even the managers: like developers, managers also want to do a good job, satisfying the needs of their employees while meeting (and exceeding) the expectations of their customers.
OK, where's the problem? That is, if the problem isn't the technology or the people, then where is it? The answer lies in the structures, processes, and outcomes that are associated with any human endeavor. Briefly, outcomes are the things produced. In software, they can be data models, source code, requirements documents, meeting notes, and so forth. Processes are the means by which we create outcomes. Structure ties everything together by prescribing a preferred process and defining the form and content of outcomes.
All human activity takes place in the context of structure. Language provides the structure necessary for communication. Our highway system provides the structure needed for transportation. The right structure enables a process that produces appropriate outcomes. A poor structure inhibits process and produces outcomes (systems) that don't work, are delivered late, and produce few (if any) reusable components.
In software development, methods provide one kind of structure. By following the processes defined in the method, we produce outcomes that enable us to build the right kind of system. But we need more than just methods. We need organizational structures that support developers working in OT. We need to keep the structure of reviews (you do engage in reviews, don't you?) but change the process and outcomes associated with reviews. We need to provide the structures that support the processes of reuse. We need to provide effective, useful training that teaches which outcomes are appropriate, the best processes to use when creating them, and the structures that are needed to support both the transition and the ongoing efforts of the organization. Such training touches everyone in the organization, from developers (who often focus on the wrong outcome) to managers (who aren't taught which structures and processes make sense for their environment). Without such training (itself a structure, process, and outcome) successfully adopting the new paradigm becomes extraordinarily difficult.
The "soft" issues of software development are inextricably bound to the structures, processes, and outcomes of the organization. By building an understanding of these elements, we can engineer them to enable ourselves and our developers to create truly effective systems.
The reason we have not had much discussion on this most difficult part of developing software is speakers can't do justice to this topic in just a couple of paragraphs. In fact, the topic is so interesting and vast, that I think it can become a study of a lifetime.
One of the many issues we could look at is "what happens to a professional when he/she has to give up well practiced problems skills, to learn new ones which offer the vague promise of a `better way of developing software.'" We see this situation frequently during the transition to objects.
These skills are used in our livelihood and often contribute to our identity. Thus these skills are very important, and not set aside easily. They certainly are not without given up without experiencing a range of emotions:
These are only a few of the kinds of emotions that someone might experience while mastering objects. There is also joy of learning, satisfaction of mastery, and the excitement of discovery.
The point here is that experiencing negative emotions is part of the process of learning about objects. In many of our work environments, we don't believe that we have the freedom to express such emotions -- instead they remain inside us, either to do damage or to sneak out in some more obscure and ineffective form of behavior.
I think it is crucial to install into your culture, the Four Freedoms of an Empowering Environment as you begin a transition to objects. These freedoms include:
If you can't establish these freedoms within your work environment as you ready to move to objects, then I recommend that the transition to objects be delayed. The Four Freedoms are a subtle but key foundation to the success of your transition to objects, and when missing, the probability of object-oriented project failure is very high.
Paul S. R. Chisholm
Paul S. R. Chisholm AT&T room LZ 1D-208 307 Middletown-Lincroft Rd. Lincroft, NJ 07738-1526 USA office: 908-576-3252 FAX: 908-576-6406 e-mail: psrc@cmprime.att.com