Communications of the ACM
What's Our Goal For a CS Degree, and How Do We Know We Got There?
Georgia Institute of Technology professor Mark Guzdial
Since the earliest formal review of American engineering education during the first International Congress of Engineering in Chicago in 1894, engineers, engineering educators, and representatives from industry and government have been assessing every 20 years or so how well our educational institutions prepare engineers for current social needs.[^1]
I read this paper for a recent (July 2013) Workshop on Integrated Engineering Education at Michigan State University. The last sentence raises an interesting question and poses an impressive goal. I met one of the co-authors of this paper there, Jeff Froyd, and he assured me that the question is raised explicitly when engineering curricula are being reviewed. Are engineers being prepared "for current social needs"?
I have been involved in several curriculum design and review efforts, both at my own school, as part of a visiting team to other schools, and as part of professional organization efforts. Common goals include preparing our students "for leadership positions" or "for successful careers in information technology" or "to meet future industry needs." I don't think I've ever heard the goal "to meet current social needs" for computer science. I've been wondering how would you know if you got there? How do we know if we're preparing students for successful careers, or if we're meeting current social needs?
Nathan Ensmenger's 2010 book "The Computer Boys Take Over: Computers, Programmers, and the Politics of Technical Expertise" challenges us to question if our computing curricula meet our goals. Ensmenger explores the history of the computing industry moving from science and engineering laboratories into everyday business starting in the 1950's. The shift created a desperate need for more computer programmers, so a variety of training programs, aptitude tests, and eventually, academic degrees were created. More academic degrees and professional organizations were established to turn computer programming into a profession.
Ensmenger argues that these efforts were not wholly successful. He points out that the academic degrees required (and still require) significant mathematics, but without supporting evidence for the requirement. While mathematical ability predicts success in computer science classes, it does not predict success in being a computer programmer. So, the mathematics requirements of a computing undergraduate degree prevented many from gaining the degree, when the requirement may have nothing to do with the goal of being a successful programmer.
The efforts to professionalize computer programming have failed, Ensmenger argues. In other professions (like medicine or law), the academic degree is critical to entry in the field. Even if there wasn't a license or credential, it's not clear that anyone could become a self-taught surgeon or lawyer. But academic degrees are not necessary to enter the computing field. We have self-taught programmers who are very successful in computing. Ensmenger presents evidence that we have not successfully defined what is necessary to succeed as a computer programmer, nor have we developed mechanisms to teach that. Ensmenger further suggests that our efforts to professionalize computing may have been a factor in reducing the percentage of women in the field, because our model of a professional software developer is built around masculine ideals.
I doubt that the attempts to professionalize computing were a significant factor in the decreasing the percentage of women in computing, but they may have been a factor. The more important question that Ensmenger is raising is what is a computer science degree for and how do we know if we're achieving that?
Being a computer science professional means more than just being a programmer. What does it take to become a successful professional in computing? Andy Begel and Beth Simon did a study computer science graduates newly hired as software developers at Microsoft. They found that the demands of the job had very little to do with what the students learned in their classes. The students' classes gave them technical skills to design and develop, but mostly what the new hires did was to collaborate and debug.
What are our goals for computer science undergraduate degrees? How do we know that our requirements are the right ones to achieve those goals? And who are we keeping out, in establishing the demands of a degree? These are important questions, especially when getting the curriculum wrong could be driving away potential developers that we need in our workforce.
[^1]: Clark, M Carolyn, Froyd, Jeffrey, Merton, Prudence, & Richardson, Jim. (2004). The evolution of curricular change models within the foundation coalition. Journal of Engineering Education, 93(1), 37-47.
Comments
Christopher Riesbeck
Mark,
Clearly a CS degree was designed to create more computer scientists, no? For learning software development, the best one can say for CS is that at least you learn multiple programming languages, data structures, some good mathematical techniques, and a computational approach to problem solving. But CS leaves out many skills, both technical, such as object-oriented analysis and design, test-driven development, and interface design and implementation, and social, such as client communication, user testing, and team development. A software development curriculum focuses on the profession of solving problems for clients and end users, not defining new areas for research. Would such a curriculum be more attractive to women and others filtered by CS? The numbers in a pilot run of an online masters in SD I'm running are too small to prove a thing, but the women in it have excelled on exactly those areas of team work and solving client problems.
Mark Guzdial
Hi Chris,
Ensmenger argues that the field "computer science" was invented to provide computer programming professionals. He reviews the history of how our field got its name (early competitors included synoetics, intellitronics, datalogy, and my favorite, hypology from the Greek for "to compute"). "Computer science" was chosen to suggest the rigor and professionalism of the field.
The items you cite as *not* part of CS ("object-oriented analysis and design, test-driven development, and interface design and implementation" and "client communication, user testing, and team development") actually are part of most computer science curricula -- see the CS2013 Ironman Draft: http://ai.stanford.edu/users/sahami/CS2013/ironman-draft/cs2013-ironman-v1.0.pdf
- Mark
Moshe Vardi
Mark, you say "While mathematical ability predicts success in computer science classes, it does not predict success in being a computer programmer." This is a strong statement! I find it counter-intuitive, as programming requires abstraction and mathematical ability predicts abstraction ability.
What is the evidence behind your statement?
Mark Guzdial
Hi Moshe,
That claim is one that Ensmenger makes, which I was relating. He cites several studies in support of his claim. I recommend the book to you.
If I was speaking for myself, not relating Ensmenger's claims, I would say that mathematical ability often but does not always predict success in computing. Michael Caspersen did an excellent review of the literature in predictors of success in computing (defining "success" here as "passing introductory computing"). While there are several studies showing a correlation between mathematical background or ability with computing success, there are also studies (e.g., P. Ventura's dissertation) where he found that mathematical ability did not correlate with success in object-oriented analysis and design.
From an educational perspective, the issue is one of "transfer." Knowledge in one context often does not translate to another context. Sure, programming requires abstraction, and mathematical ability requires a form of abstraction. But can students transfer the knowledge gained from mathematical abstraction and apply it to computing abstraction? Do students see them as the same thing? Orit Hazzan has done a lot of work showing how students resist developing abstractions and seeing opportunities to transfer. The better the student, the more likely transfer will occur, but it doesn't always happen.
Displaying all 4 comments