Communications of the ACM

How do we break the cycle of negative interference as experts in one programming paradigm learn a new, and very different, programming paradigm?

To determine the effectiveness of the course, we followed the students over a two-year period interviewing them one month, one year, and two years after the class. We compared the results with interviews of programmers who were following the traditional route and were at a similar point in their OO training programs.

One month after the class, the OO Thinking students had difficulty remembering the formal definitions of OO terms such as class, instance, and polymorphism. This was expected as they were finishing their procedural programming projects and had not yet begun their OO training program. However, they did remember OO concepts and did realize that OO programming is significantly different than procedural programming. From one student: "I think that I would know when I'm drifting astray. ... I'd have an idea that I was drifting into `Structured Land.' Enough to stop myself before I went the full route."

After one year, the students had taken several OO modeling courses and language courses in C++ and/or Java. In the interviews, one result was striking. The OO Thinking students had no mental mappings from OO concepts back to procedural concepts. For example, they were asked a leading question such as, "How do you map the OO concepts you've learned and use to structured concepts?" A typical response was, "I don't think you can come up with a comparison that says this concept maps with another concept. It's a really different way of doing things." This contrasts sharply with the responses of programmers in the process of transition and who did not have the OO thinking course. With a similar amount of OO classroom and on-the-job experience, their mapping was strong: "Methods map to procedures. Data flows map to messages. I do think of methods very much like a subroutine."

After two years, the gap between the OO Thinking students and the traditional training students had narrowed considerably. With more classes and development experience in the past year, both groups were performing at approximately the same level. Although the mapping from OO concepts to procedural concepts for the traditional students had been almost eliminated, some mappings were still revealed during the interviews.

Although the OO Thinking students were not mapping OO concepts back to procedural concepts, were they thinking about OO development correctly? To determine this, we interviewed OO experts from the same organization. These experts all had more than 10 years of OO experience and were identified as the "OO gurus" in the organization. A comparison of the interviews of the OO Thinking students, the OO experts, and the traditional students revealed that the first two groups believed the shift from procedural development to OO development truly involved a shift in thinking. For example, "You need to think about the OO concepts differently. The whole way you look at the problem is different, not the same ways as with, say, Fortran." On the other hand, the traditional training students did not see much of a mindshift: "It's an evolutionary change rather than a revolutionary change. The concepts have been there a long time, it's just packaged differently in OO."

1. Tell me about your experience in procedural (structural) programming.
2. What do you call the piece of work you work on? What is the smallest piece that a person would typically be working on?
3. Is there a process you follow?
4. Once you get to that level, what do you do?
5. What do you do when you have more complex systems to build?
6. What's the first thing you think about?
7. What do you do when dealing with very small pieces of code?
8. How do you code and come up with a black box?
9. Do you follow any specific order? Top to bottom?
10. How do you know how to do it from requirements?
11. What is it that you do to get what the user wants?
12. Suppose you're done with the requirements document, what do you do to turn it into code?
13. Is there a method to decide functionality?
14. What's the next level of decomposition?

Building a Shared Vision

1. What changes in a system?
2. What sort of business rules?
3. How? What's different?
4. What initiated the change?
5. What causes change?
6. Is it easy to generalize code?
7. How can you write software so things don't change as much?
8. How do we create a system so it responds well to change?
9. What is data?
10. What are the characteristics of data?