ences: students looking to computer science as the basis for visual studies or biology rather than preparing them for a software-oriented career. There is no one-size-fits-all solution to addressing the skills and knowledge needed to succeed in these areas. Should we expect Craig Venter or Gene Myers to ask computer science programs to include more computational biology because the demand for bioinformati-cians exceeds supply? Will we be surprised if Ken Perlin asks for programs to embrace games and graphics more than they do to ensure a steady supply of people interested in animation or computer-generated imagery? We are discussing the requirements and curricula of an undergraduate degree! Our programs can certainly build a superb foundation on which students can continue to gain knowledge and skills as they work and study in different areas, but we should no more expect students to be expert or even journeymen than we expect our premed students to be able to remove an appendix after four years of undergraduate study.
As Fred Brooks reminded us more than 20 years ago, there is no silver bullet that will solve the problems endemic to software development nor is there a panacea to cure the ills that may plague computer science curricula and programs. 2 Studying more mathematics will not make software bugs disappear, although both Dijkstra and Dewar seem to think so. Dewar points out the need for “formal specification and proof of correctness techniques” as foundational for software development using Ada. Dijkstra tells us “where to locate computing science on the world map of intellectual disciplines: in the direction of formal mathematics and applied logic,” but pines for Algol rather than Ada. Both miss Brooks’ point about the essential complexity of building software, the essence in the nature of software. In a wonderful treatise that has more than stood the passage of 20 years and in which he presciently anticipated the tenets of Agile software methodologies, Brooks claims that “building software will always be hard,” and that this essence will not yield dramatic improvements to new languages, methodologies, or techniques.
Brooks has hopes that the essential
aspects and difficulties of software may be improved by growing software rather than building it, by buying software rather than constructing it, and by identifying and developing great designers. He differentiates between essential and accidental aspects of software where accidental is akin to incidental rather than happenstance. Changing programming languages, using MapReduce or multicore chips, and employing a visual IDE in introductory courses address these accidental or incidental parts of software development, but these don’t mitigate the essential problems in developing software nor in educating our students. As Brooks notes, addressing these accidental aspects is important—high-level languages offer dramatic improvements over as-sembly-language programming both for software design and for introductory programming courses. 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.”
3
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 ef-
fects 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 and Bjarne
6
Stroustrup. 5 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.”
References:
Archives