I have been reading the other position statements and find them interesting, thoughtful and encouraging. Here is what I found when I tried to isolate my position with respect to those other positions:
They say to teach "good design" but do not say what "good design" means, or even what "design" means. I should like to offer that:
* OO design means partitioning the system (as opposed to algorithm design)
* Good OO design means supporting the system's future evolution.
To me, teaching OO design means to discuss partitioning, and teaching on how "good" an OO design is is teaching how to read the future the design supports. Most of what I read in the other positions is in harmony with these definitions and views, but do not make them explicit. I wish to make them explicit, in order to sharpen the conversation.
What would you teach a group of novices you would have to, yourself, use on a live project next week? How would you teach them? That is my audience and goal. I have come to the following 10-point position:
The position paper is a story which outlines the background for each of the ten points, and how I feel about this way of teaching, compared to the "usual" way.
I am a professional programmer, consultant, teacher, with 20 years of hardware, software, research, consulting experience. I have taught professionally for 6 years now, all on OO. I teach in industry, as opposed to academia. I am getting the impression that academia does a few things differently and better than I have seen in industry, and would like to learn what they are, how to incorporate those differences. The most interesting difference I saw was in a computer graphics class, in which the students were made to replace the modules in a paint program one at a time, from the line-drawing through the user-interface modules. The difference was that the students always had an interesting program to run, rather than a "hello, world". I have not met anyone doing that in industry.
I teach design, not programming, and am most concerned with whether the students understand design tradeoffs. Without those, they have nothing. I continually meet graduates of OO programming classes who can name the classes in the library, and graduates of OO A&D classes who know cardinality rules, but cannot begin to articulate how the design might look or why one choice is better than another. My interest in the workshop is to trade ideas with other teachers, especially those from academia, about how to give students design thinking ability, and how that ability might manifest itself.
I should like to stake the following positions, which weave into a total current position:
"If I had to use a brand new developer, after only 4 days of classroom teaching, what would I insist they know so I could trust them with a design problem?" I was project lead looking at using new developers and needed a course. I suspect this is a suitable question to include in a college curriculum.
This position statement recapitulates the lessons I learned teaching an OO design course, and where I look for improvements in the future. The 10 points above summarize the place from which I currently operate. I can only contribute to the workshop by telling a story...
I created the OO design course while project lead, when I realized that I could send my new team of novices to every OO course in IBM and KSC, a total of about eight 40-hour weeks, and they would still come back to me without being able to "do design". They can draw OMT diagrams if they have been to an "analysis" class, or locate the UI classes if they have been to a "programming" class, but they cannot examine or create a design. I do not disparage IBM or KSC, they are merely typical. All the courses I examined at that time (including the ones I taught) taught concepts, analysis and design notations, and programming, as though it were sufficient to describe all the buttons on an electric piano and then expect the person to be a musician.
My answer was: Teach them how to do a simple design. Later they can learn how to do a harder bit of design. That means, teach them how to think about design, how to make tradeoffs, how to talk about the consequences of their design. I liken this to teaching them piano with half notes on white keys, later adding syncopation and black notes. So far, this metaphor has held up. To support it requires that the class be 2/3 lab time, and only 1/3 lecture time. While I am lecturing, they are not learning design. Learning design comes from their exercises, and our common discussions about their designs. We start by asking: "What constitutes a design?" I do this because I do not know, myself, notwithstanding 20 years of experience, leading, teaching, designing methodologies.
They design a bank - the whole thing, not just the computer system - in 45 minutes, and show their design on two overhead foils. The contest is which team made overheads that would best communicate, to someone dragged in off the street, how their bank is "designed", compared to any other bank. The exercise warms them to the topic of showing and reading a design. The winner usually shows
I have to give them some methodology. How else can they share their results? How else can they, as newcomers, start to work? I chose use cases, CRC cards and interaction diagrams as the simplest as well as the most effective techniques to teach. Use cases are part of requirements, so they learn about requirements in the design class - how to create them, what to expect from them. Responsibilities and interaction diagrams are the single best way I have found to brainstorm, convey and evaluate designs.
If I let them out of the class with nothing formal at all, then they do not know what is essential to document when they get onto a project. The formality I insist on is not OMT notation, it is writing down the class's abstraction and responsibility at the same time as writing down its name, it is writing down the purpose and result of a function as part of its creation.
In the end, they "program" their designs with interaction diagrams, which is a nice, language-neutral programming technique.
We assess the designs together. The teacher's experience and openness are crucial. I discover again and again that very design they produce is a) object-oriented and b) adequate to the problem. The difference between designs is how they lead to the future. It is my job to open the discussion to the different futures the designs support, and let them discuss the futures they think are worth supporting. From this they start to get the idea of design quality, and comparing designs. Everything else in the class is subsumed to these comparisons. It is the most wonderful feeling when I see my students on a project, discussing communication patterns, responsibilities, and trajectory of change on a whiteboard, even when the designs are quite simple. I use 5 exercises: a bank, a coffee vending machine, and a pizza delivery service, because everyone has seen those things; a large project involving designing a purchasing / tracking system, which nobody has seen before; and an account log involving a sorted collection.
I do have another exercise I would consider critical in this or the next course - configurable algorithms (using inheritance overriding). I would not expect a new OO designer to know that after just one week, but I would wish them to learn that immediately next.
My experience is that good, experienced designers, even coming from structured programming backgrounds, produce good, robust and subtle OO designs. They know how to recognize the issues. Programming novices produce simple-minded designs. Therefore, I have reduced my expectation of how much "design quality" can be taught in 30 hours. I could imagine that an academic course could give the students more time to learn subtlety in design.
"Object-think" is theirs by end of day two. On day three we rediscover that they have made a simple function into an object. I stress to them that this is OK sometimes, and then we cover how to decide if it is not OK. It is usually not OK in the situation that shows up on day three - they typically turn the function "print" (or similar) into an object - and this is a lesson that I desperately need them to encounter in this first week.
I include design patterns under the heading of "documentation", and have found that they are too difficult for the students to get within the first week.
Finally, I make all the exercises as open-ended as possible, so they have to set their own scope and finish requirements for each problem. The intent of this is to give them some idea of scoping issues.
What is wrong and what still lacking?
The design course is different from any I have seen in industry, which is why I outlined it. I aimed it at a very specific audience with a very specific goal. I should like to recommend that audience/goal pair, even in universities.
The lessons learned teaching the course have given me the particular 10-point position outlined at the top. Some of those points were not obvious to me at the start, so they might not be obvious to other workshop attendees. The most particular of those is the matter of regarding an OO design though the future it supports.
I wish to share these experiences with others (or even the same) from academia, and learn other teaching techniques.
I have discussed several different approaches.
The "standard" industry technique is to show the student all the language or notation features and then send them on their way. This teaching technique is nice for the teaching company because it is easy to reproduce. It does not teach the student how to think about design.
The way I discussed relies heavily on the teacher being able to bring forth the futures implicit in each design. That is difficult, it relies on substantial experience in the teacher. It only replicates to other experienced designers.
The "standard" academic approach, as I have seen it, it to focus on data structures and algorithms for problems the student will probably not encounter more than twice in their career. It does not teach partitioning, which is the heart of OO design. I have seen delightful university courses in which students replace modules on a large(ish) system. I think this is more useful than most approaches.
Finally, I just encountered the synergogic technique, in which the instructor prepares material and questions in advance, and lets the students discuss and evolve their own evaluation criteria to answer the questions. It looks promising to me, but I have not yet tried or seen it.
Mouton, J., Blake, R., Synergogy, Jossey-Bass Publishers, 1984. This is about teaching adults by letting them create their own evaluation framework for materials provided by the instructor.
Alistair Cockburn started as a hardware designer in 1975 for Evans & Sutherland, designing 3D flight simulator visuals on a team of 26. That was the first lesson in learning about, doing and evaluating designs. He started teaching OO concepts and Smalltalk programming (note the absence of design) while at IBM Research, in Zurich. He became focal point for OO in the IBM Consulting Group, responsible for building a methodology for IBM service teams. He left IBM in 1994 to found Humans and Technology in Salt Lake City. He was lead consultant, design mentor and team lead on a 2-year, 45-person OO project. He currently develops tailored methodologies, teaches OO design, consults, writes and leads projects.