What’s Our Goal For a CS Degree, and How Do We Know We Got There?

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.