Jutta Eckstein
Objects in Action
Thierschstr. 20
80538 Munich, Germany
+49 89 2248 27
jeckstein@acm.org

Richard S. Wiener
University of Colorado at Colorado Springs
Austin Bluffs Parkway
Colorado Springs, CO 80906
+1 719 579 9616
rswiener@acm.org

Since the emergence of Object Oriented Technology (OOT) in the software industry, users of OOT have needed to be trained in its concepts and techniques. Since OOT‘s inception, educators and trainers have been struggling with how they can make teaching OOT easier. It’s still hard to teach OOT, because all the people dealing with OOT in analysis, design and programming have to make a paradigm shift for learning OOT. The central point of this paper is to show that learning OOT is made more difficult because we educators ourselves still haven’t made the necessary paradigm shift in teaching OOT.

hit-or-miss-fashion, multiple way communication style, pedagogical patterns, task and reflection in learning

Discussions at conferences like the Educators’ Symposium (at OOPSLA) clearly show that those of us involved in OOT training still feel it’s difficult to teach OOT. And it doesn’t matter where the education takes place - it’s equally hard to effectively teach OOT in industry as well as in academia.

But why is teaching OOT hard? Most of us share the idea that teaching OOT is hard because the students have to make a paradigm shift. And that’s absolutely true, especially when the students are previously educated in structured programming. But that’s only half the truth, because if all the people dealing with OOT in analysis, design and programming have to make a paradigm shift for learning OOT, then it should also be necessary for the educators to make the paradigm shift in teaching OOT. The way we taught structured programming doesn’t work for teaching OOT. This means we have to change the way we teach. In summary, picking up OOT is difficult for the students, because we educators still haven’t made the paradigm shift.

• The people have never learned to do abstractions
• Instead of teaching real OO concepts, often something like POOP -– procedural OO programming – is taught
• Waterfall style training hinders. This means that teaching the way the material is presented in books, e.g. Analysis-Design-Implementation..., doesn’t help the students. They never get the idea about the incremental and iterative approach, because they have never experienced it themselves.
• Complexity reinforces the need for OO

For overcoming these issues, we agreed that there is a need for a Paradigm Shift in teaching.

The shift to OOT covers all areas. Not only analysis, design and programming are affected by the shift, but also project management, mentoring, teamwork and training. Paradigms are often broad and fuzzy collections of ideas, approaches and techniques to solve problems. Adopting a paradigm requires a great deal of learning along with deep changes in perception, attitudes and actions.

The way most of us teach right now is in a rather formal and structured manner. As it is already reflected in the word structured it becomes obvious that this has really nothing to do with OOT. This lecture style teaching doesn’t provide much feedback and it makes it hard to assess whether the material is understood by the students.

Figure 1: Hit-or-Miss-fashion (Structured way of teaching)

The idea here is that our very approach to teaching can also be done in an OOT way, and doing so will make the teaching much more effective. This means we have no more ‘main program’ - the educator - but a lot of small and self-responsible objects that interact with each other. In this approach, each student is responsible for his/her learning, has a well defined interface, and so on.

The student‘s learning process is triggered by events and messages from the outside or other objects, which could be students or the educator.

The multiple way communication style, supported by Pedagogical Patterns and Empowering in communication, which are explained below, seem to be a great idea, but we as trainers often think that we never can use them because our students wouldn’t take us seriously. In order to be successful in using these tools, we have to change our attitudes.

The best way to encourage in communication is by reinforcing in teamwork and by assigning problems to small groups. But we all agreed that what always helps most is Education through socialization, which has an more interdisciplinary characteristic.

It is also important to provide enough space for the students so they can learn on their own. With space we mean a learning climate, which allows the students to learn from another. One example is the jigsaw puzzle „classroom", developed by UC Santa Cruz professor Elliott Aronson [2]. Here a topic is assigned to each student. They have to understand the topic in such a way that they’re able to teach the others. For many people teaching is a great way to learn, and provides an accurate indication of how well the student understood the topic. In this approach, the trainer plays more the role of a control manager, who ensures the correctness of the contents.

• Teaching documentation, a good way to do that is by passing the applications from one team to another one. If the application isn’t well documented the team members will realize it very fast and they do want to overcome that problem by themselves.
• Run an example project over several years. This is an example Jim McKim is doing: he’s running a single project over several years. The students change the project and evolve the system over time. This shows reuse and makes also obvious to the students that documentation is not an unnecessary task.
• Role playing helps a lot

• The role of basics in teaching. One of the participants had really good experience in teaching any OO language in an Eiffel style. So he’s always focusing on the differences of fields, constructors, commands and queries.
• Design Patterns: we agreed that it is risky to teach Design Patterns as a stand-alone topic. But we found it important to point to them for improving a design when they’re appropriate.
• We didn’t really agree on how important it still is to teach procedural programming and thinking. If we should it at all and if yes when. But most of us had sometimes the problem that the students were not able to implement an algorithm when the first programming theory they learned was OT.

We had a very valuable discussion, although (or because?) of the lack of enough participants. What hindered the workshop a little bit, was that we combined this workshop with the one from Ed Gehringer: Reuse Experiences in Teaching. On the one hand we had more people being interested in the topic of teaching in general but on the other hand we had two topics to cover. So we had sometimes problems in keeping the focus.

I thank all the participants in the Think-Tank at the OT'98 in Oxford and in the Workshop at OOPSLA’98 for their valuable contributions.

1. Anderson, Bruce. Task and Reflection in Learning to Learn. Empowerment through Experiential Learning. Kogan Page, London, 1992.
2. Aronson, E., Brigman D.L., Oeffner R. Interdependent interactions and prosocial behavior. Journal of Research and Development in Education 12, 1978, 16-27.
3. Birkenbihl, Michael. Train the Trainer. Handbook for trainers and university lecturers. mi, Landsberg/Lech, 12th d. 1995.
4. Lazarus, Eric. Toward object-oriented mentoring methodology. In JOOP 8 (6), Oct. 1995, 64-72.
5. Lilly, Susan. Patterns for pedagogy. In Object Magazine 5(8), Jan. 1996, 96-95.
6. Manns, Mary Lynn and Prieto, Maximo and Mc Laughlin, Phil and Sharp, Helen. Workshop notes. Workshop on Pedagogical Patterns. OOPSLA ’96, San Jose, CA, October 1996.
7. Watzlawick, Paul et.al. Pragmatics of human communication: a study of interactional patterns, pathologies, and paradoxes. London, Faber, 1968.

Related Workshops

8. Eckstein, Jutta. Think-Tank. A Paradigm Shift in Teaching OOT. OT‘98, Oxford UK, 1998.
9. Manns, Mary Lynn and Prieto, Maximo and Mc Laughlin, Phil and Sharp, Helen. Workshop notes. Workshop on Pedagogical Patterns. OOPSLA ’96, San Jose, CA, October 1996.