This workshop is about teaching design during the first year of university instruction. Not just for the sake of argument I will take the position that we shouldn't do so. At UCSB we have just revised the first two years of our undergraduate CS curriculum so that the new second-year design course hasn't been taught yet. But in the tradition of computer science I will not be deterred from making strong claims based on missing empirical data...
At UCSB we are starting with a revised pre-major introductory course sequence this Fall, using Java as the introductory programming language. The six-quarter course sequence consists of the following courses:
Discussion
Our curriculum revision was originally motivated by the desire to switch to an object-oriented language as the first programming language and by faculty who were teaching programming-intensive upper-class courses (e.g., advanced data structure or OS courses) and observed that the programming skills of many students were inadequate. In this context, "programming skills" refers to the collection of skills needed to go from a problem description to a good solution (in the form of a program). For some students, the problem was in designing an appropriate solution, for others it was in implementing and/or debugging non-trivial programs. "Non-trivial" is key here: most students had no problems in designing and implementing 200-line programs, but many students struggled when asked to produce an algorithm-intensive 1,000-line program or to modify and extend an existing OS simulator consisting of about 10,000 lines of C++. Clearly, the existing pre-major course sequence did not adequately prepare students for these challenges.
The previous incarnation of CS 20 contained aspects of design such as interfaces/ADTs and program modularization. However, we found that by the time students reached the third year most of the lessons learned in that course had been forgotten. We attributed this problem to two main factors: first, there wasn't enough time to cover the issues thoroughly, and second, none of the second-year courses reinforced them (maybe with the exception of the CS 60 precursor). Thus, we set out to correct this problem by emphasizing both programming and design in our pre-major courses.
However, contrary to the trend that this workshop appears to indicate, we felt that expanding the treatment of design during the first year would not benefit most students. Personally, I would state it in even stronger terms: teaching design before students have thoroughly mastered programming-in-the-small is a waste of your time and the students' time. There are several reasons that have led me to this opinion:
1. Lack of grounding. Without solid programming skills, students have too many simultaneous problems at too many levels and thus will be lost at sea trying to solve design problems. For example, if you're unsure about the exact semantics of inheritance there's no point in trying to design inheritance hierarchies. In my experience, it takes several thousand lines of code (cumulatively)-typically, about a year of exposure to programming-before students with no prior programming experience are reasonably comfortable with programming in the small.
In a way, the situation reminds me of teaching English, i.e., teaching spelling and grammar vs. teaching composition. Do people teach composition in first grade? No, because the student's grasp of sentence-level structure isn't developed well enough to start thinking about composition. That doesn't mean that student's can't be exposed to well-composed essays-just that we can't expect them to write them.
2. Lack of relevance. When writing small programs, design (and generally, good programming style) isn't that important. Even with a bad design or unstructured coding the program's complexity remains
manageable and the benefits of a better design may not be apparent. In fact, it may actually take more effort to write a well-designed program since the design itself takes time. But if design isn't rewarded with a concrete payback such as spending less time doing homework assignments, students may do it only because they're forced to, not because they're convinced of it. As any psychologist will tell you, such extrinsic motivation is vastly inferior to intrinsic motivation.
3. Lack of continuity and reinforcement. A design course should be followed by other courses where students can apply their newly acquired skills in practical situations. If the time gap becomes too long, much of the knowledge may be lost because it wasn't yet firmly ingrained in students' brains. Unfortunately, software-intensive courses (i.e., courses with substantial programming assignments) usually aren't scheduled until the Junior and Senior years of the undergraduate curriculum. If design is taught during the first year, students will spend over a year (including the summer break) without applying their skills on realistic programs.
To address these problems, we created a new course (CS 50) that will be offered in the winter and spring quarters of the second year. By that time, students will have had sufficient exposure to programming, algorithms, and theory, so that they are ready to tackle challenging programming assignments. CS 50 is designed to solidify the programming skills while teaching design and other basic software engineering
skills. By having students implement their designs and rely on other students' designs as part of group projects, we hope to not only teach good design but convince students of its importance. For example,
changing the requirements after a first prototype is delivered will reward students who thought about flexibility up-front. Everyone makes mistakes, and we hope to let students make their first "big" mistakes
in the first half of this course. Hopefully, this will make their upper-class years much more productive and rewarding. However, this approach hinges on students having solid programming-in-the-small skills when they enter the course, something we feel they won't have without first taking the CS 10/20/30 series during the first four quarters at UCSB.
Let me return to the analogy with teaching English: yes, composition is important, and everyone coming out of school should know and master it. But students need to master the basics first-the value of composition will be lost on first graders. Sometimes, later is better. Design during the first year? Just say no!
Biography
Urs Hvlzle is an Assistant Professor of Computer Science at the University of California, Santa Barbara (Ph.D. Stanford University, 1994) and the recipient of a 1996 NSF CAREER Award. His research interests include object-oriented programming languages, compilers, and run-time systems.