936 TEACHING THE METHOD $29.1 T3 is not a typo:after having tried to apply O-O ideas to real development,trainees take the class again.O-O training companies sometimes suggest this strategy to their customers,not always with success since it suspiciously looks like a marketing ploy to sell the same thing twice.But that is not the case. The second iteration is what really gets the concepts through.Although the first is necessary to provide the right background,it may not be fully effective,partly because of the mOOzak effect,your students may not quite internalize the concepts.Only when they have grappled with the day-to-day challenges of object-oriented software construction- Is a new class necessary for this concept?Is this a proper use ofinheritance?Do these two features justify introducing a new node in the inheritance structure?Is this design pattern from the course relevant here?-will they have the necessary preparation to listen properly.The second session will not,of course,be identical to the first(if anything,the audience's questions will be more interesting),and might straddle the border between training and consulting;but it is really a second presentation of the same basic material- not merely an advanced course following an elementary one. In practice only the more enlightened companies are ready to accept the "teach it once, then teach it again"strategy.Others will dismiss the idea as a waste of resources.In my experience,however,the result is well worth the extra effort.The strategy is the best I know to train developers who truly understand object technology and can apply it effectively to serve the company's needs. The next principle addresses what should be taught: Training Topics principle Especially in initial training,focus on implementation and design. Some people assume that the curriculum should start with object-oriented analysis. This is a grave mistake.A beginner in object technology cannot understand O-O analysis (except in the mOOzak sense of recognizing the buzzwords).To master O-O analysis,you must have learned the fundamental concepts-class,contracts,information hiding, inheritance,polymorphism,dynamic binding and the like-at the level of implementation,where they are immediately applicable,and you must have used them to build a few O-O systems,initially small and then growing in size;you must have taken these projects all the way to completion.Only after such a hands-on encounter with the operational use of the method will you be equipped to understand the concepts of O-O analysis and their role in the seamless process of object-oriented software construction. Two more principles.First,do not limit yourselves to introductory courses: Advanced Curriculum principle At least 50%of a training budget should be reserved for non-introductory courses. Finally,do not consider developers alone:936 TEACHING THE METHOD §29.1 T3 is not a typo: after having tried to apply O-O ideas to real development, trainees take the class again. O-O training companies sometimes suggest this strategy to their customers, not always with success since it suspiciously looks like a marketing ploy to sell the same thing twice. But that is not the case. The second iteration is what really gets the concepts through. Although the first is necessary to provide the right background, it may not be fully effective; partly because of the mOOzak effect, your students may not quite internalize the concepts. Only when they have grappled with the day-to-day challenges of object-oriented software construction — Is a new class necessary for this concept? Is this a proper use of inheritance? Do these two features justify introducing a new node in the inheritance structure? Is this design pattern from the course relevant here? — will they have the necessary preparation to listen properly. The second session will not, of course, be identical to the first (if anything, the audience’s questions will be more interesting), and might straddle the border between training and consulting; but it is really a second presentation of the same basic material — not merely an advanced course following an elementary one. In practice only the more enlightened companies are ready to accept the “teach it once, then teach it again” strategy. Others will dismiss the idea as a waste of resources. In my experience, however, the result is well worth the extra effort. The strategy is the best I know to train developers who truly understand object technology and can apply it effectively to serve the company’s needs. The next principle addresses what should be taught: Some people assume that the curriculum should start with object-oriented analysis. This is a grave mistake. A beginner in object technology cannot understand O-O analysis (except in the mOOzak sense of recognizing the buzzwords). To master O-O analysis, you must have learned the fundamental concepts — class, contracts, information hiding, inheritance, polymorphism, dynamic binding and the like — at the level of implementation, where they are immediately applicable, and you must have used them to build a few O-O systems, initially small and then growing in size; you must have taken these projects all the way to completion. Only after such a hands-on encounter with the operational use of the method will you be equipped to understand the concepts of O-O analysis and their role in the seamless process of object-oriented software construction. Two more principles. First, do not limit yourselves to introductory courses: Finally, do not consider developers alone: Training Topics principle Especially in initial training, focus on implementation and design. Advanced Curriculum principle At least 50% of a training budget should be reserved for non-introductory courses