Crossroads - Fall 2009

Robert Dewar & Owen Astrachan

Brooks’ view, which I share, calls for “Hitching our research to someone else’s driving problems, and solving those problems on the owners’ terms, [which] leads us to richer computer science research” [ 12]. I will return to problem-driven approaches later.

It would seem from the juxtaposition of amusing anecdotes regarding flawed software systems that Dewar would like to make the academic community and the larger computer science and software communities aware that a simple change in attitude and programming language in our colleges and curricula will help make the world more secure and safe with respect to the reliable systems on which it depends. Although software runs on computers it produces outputs and effects that transcend computers. It was not a simple bug in Moody’s computer system that caused constant proportion debt obligations to be incorrectly assigned the AAA rating. The model that Moody used was likely incorrectly parameterized. Even if the flaw was related to code, rather than to a model, Moody‘s correction of the model did not lead to a change in the AAA rating as it should have because of larger and more deeply entrenched financial and political concerns. Standard and Poor’s model also assigned the AAA rating to the same constant proportion debt obligations. Both services eventually lowered their ratings, but arguably these actions were insufficient.

Blaming the current economic crisis even in part on software errors is more than a stretch. Similarly, Dewar notes that U.S. vice presidential nominee Sarah Palin’s email account was compromised and that a Web site was hacked, implying these are security failures that might be fixed if only we didn’t use Java in our introductory courses. Because Governor Palin used Yahoo mail for what appears to be at least semiofficial business, her password recovery mechanisms were based on publicly available information such as her birthday, and her hacked email was posted on 4chan and Wikileaks: this is a case study in social engineering rather than one in secure systems.

Dewar’s claim that Java is part of a “dumbing down” of our curricula has been echoed in other venues, notably by Joel Spolsky [ 15] and Bjarne Stroustrup [ 14]. However, Stroustrup notes that it isn’t the language that’s a problem—it is attitude. He says, and I agree that: “Education should prepare people to face new challenges; that’s what makes education different from training. In computing, that means knowing your basic algorithms, data structures, system issues, etc., and the languages needed to apply that knowledge. It also means having the high-level skills to analyze a system and to experiment with alternative solutions to problems. Going beyond the simple library-user level of programming is especially important when we consider the need to build new industries, rather than just improving older ones.”

These articles, like Dewar’s, associate Java with a “dumbing down” of curricula. Spolsky specifically mentions the school at which I teach as one of the new JavaSchools. He laments that our students are lucky in that: “The lucky kids of JavaSchools are never going to get weird segfaults trying to implement pointer-based hash tables. They’re never going to go stark, raving mad trying to pack things into bits.”

We didn’t become a JavaSchool because we wanted to avoid segfaults, pointers, and bits. We use the same assignments and have the same attitude we did when we used C++. We switched from C++ for well-founded pedagogical reasons: Java is a better teaching language for the approach we were using than C++. Note that I’m not claiming Java is the best language for every program, but we spend much more

time in our courses dealing with the Brooksian essence of programming, algorithms, and software using Java rather than with the accidental aspects symbolized by the kind of cryptic error messages that result from misusing the STL in C++. Our switch to Java was grounded neither in perceived demands from industry nor in an attempt to attract majors to our program, but in working to ensure that our beginning courses were grounded in the essence of software and algorithms.

We must work to ensure we attract motivated and capable students, not because it is incumbent on us as faculty to train the next generation of software engineers, but because it is our responsibility as educators and faculty to encourage passion and to nurture and increase the amazing opportunities that computing is bringing to our world. It is highly likely that some programming languages are better for teaching, others are better for Ajax applications, and the right flavor of Linux makes a difference. But we shortchange our students and ourselves if we live at the level of what brand of brace and bit or drill is best for a carpenter. Instead, we should look for problems that motivate the study of computing, problems that require computation in their solution.

Just as we cannot escape the essential complexity and difficulty of developing software we cannot escape the essence of undergraduate education. We each bear the burden of our past experiences in constructing models for education. In my case this is the grounding of computer science as a liberal art, since my education began in that realm. For others, computer science is clearly an engineering discipline and to others still it is a science akin to biology or physics. We don’t need to look for which of these is the correct view; they are all part of our discipline. The sooner we accept differing views as part of the whole, rather than insisting that our personally grounded view is the way to look at the world, the sooner we will make progress in crafting our curricula to meet the demands and dreams of our students.

Biography

Owen Astrachan ( ola@cs.duke.edu) is professor of the practice of computer science at Duke University and the department’s director of undergraduate studies for teaching and learning.

References

1. Andriole, S. J. and Roberts, E. 2008. Technology curriculum for the early 21st century. Comm. ACM 51, 7. 27-32.

2. Brooks, F. 1987. No silver bullet: Essence and accidents of software engineering. IEEE Computer 20, 4. 10-19. (Reprinted in The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition. Addison-Wesley, 1995.)

3. Brooks, F. 1996. The computer scientist as toolsmith II. Comm. ACM 39, 3. 61-68.

4. Dijkstra, E. 1984 Keynote address at ACM South Central Regional Conference. http://www.cs.utexas.edu/users/EWD/ transcriptions/EWD08xx/ EWD898.html.

5. Maguire, J. 2008. Bjarne Stroustrup on educating software developers. Datamation. http://itmanagement.earthweb.com/features/ article.php/3789981/.