Are Computer Science departments abandoning Computer Science?

Academics Fail to Instill Professionalism

by Conrad Weisert
October 5, 2005
© 2005 Information Disciplines, Inc.

This article may be circulated freely as long as the copyright notice is included.


Conventional wisdom overlooks main problems

Business executives and recruiters complain about academic programs that fail to prepare graduates for the so-called "real world". They view the stereotypical course content as emphasizing theoretical minutiae over practical concerns. The student is perceived to have mastered sophisticated data structures and algorithms, but to have no conception of project budgets, target dates, user satisfaction, or the nature of mainstream computer applications.

That's sometimes fair, but it's hardly the worst shortcoming of today's college-level education in Computer Science or Business Administration.

Ignoring software quality

Who Am I to Criticize?

I'm a non-academic computing professional with ongoing professional contacts with university faculty and administration in Computer Science, Business, and Engineering. I hold a recent (1992) MS in Computer Science (Artificial Intelligence) and have taught credit courses in four institutions.

I'd like to hear from readers who know of more positive examples of Computer Science or related academic departments, and I'll be glad to revise this article accordingly. Perhaps we can post an honor roll of institutions that have a truly professional Computer Science faculty. —CW

Many institutions, including some of the most prestigious universities, place little emphasis on software quality, sometimes none at all.

In programming courses students become accustomed to getting an A grade on any program that runs to completion, produces the right answer, and uses the prescribed algorithm. Those students may later be shocked to discover that there's far more to software development. Some of them may never discover it, pursuing remunerative careers in body-shop contractor firms where their shoddy end products do little short-term damage to their employer's bottom line, but inflict immense long-term harm on their employer's customers.

Too many instructors are themselves unaware of essential principles of software quality. Students not only report getting astonishingly naïve guidance, but also complain of being penalized by their instructor (more likely by a teaching assistant "grader") for applying long-established good practices! (In an article about program quality, I reported an embarrassing incident where I inadvertently revealed to a student the programming incompetence of one of his other instructors, a full-time faculty member.)

Even those instructors who are well aware of good techniques, confronted with huge enrollments, may have little time to evaluate each student's work critically. As a result, many students get no feedback on their work except "points off" for deviations from some orthodox solution.

In the academic courses I teach I announce a grading policy that's more like those of traditional courses in liberal arts. A few students find it hard to accept at first, but many of them eventually express appreciation.

Practicing what we preach

Although software engineering courses urge students to practice enlightened methodology, the faculty who teach Computer Science courses often deviate from the very practices they and their colleagues promote. Here are two examples:

  1. Specifications

    Unfortunately pure Computer Scientists often look down upon Systems Analysis as a peripheral discipline that doesn't quite belong to Computer Science. Some schools have dropped Systems Analysis from the curriculum, and others require it only of those Computer Science majors who opt for an "Information Systems" concentration. It follows that many Computer Science faculty are unaware of criteria for documenting software specifications.

  2. Component reuse

    When I raised this issue last year with a senior professor of Computer Science, he agreed that the department ought to support such a component library. I then offered to set it up1 for them pro bono. Over the following weeks his enthusiasm cooled, presumably because his colleagues or the department chair didn't share our view of its value. I repeated my offer, but nothing ever came of it.

Departmental collegiality

As Computer Science departments grow, their faculty lose touch with one another. In a department with several dozen full-time faculty, they may not even all know one another by name or by sight. It's hardly surprising, then, that they're unaware of what their colleagues are teaching. This is more troublesome in Computer Science than it would be in more stable fields, since some course content is influenced by fad methodologies and short-lived development tools.

A generation ago, local chapters of ACM and IEEE counted university faculty among their most active members, often as officers. By attending the monthly chapter meetings faculty members were able:

Today, however, we see few full-time faculty at such meetings. When asked, they claim to be swamped by increasing course loads and other demands. (Didn't they teach courses before?) A few admit that they've "heard it all" and no longer find the presentations enlightening. It's particularly sad when they don't turn out to support one of their own colleagues when he or she is the featured speaker.

Departments that used to hold regular internal colloquia as part of or in addition to department meetings are giving them up, because so few people were interested.

Of course, except in trade schools, there's no requirement for faculty within an institution to agree with one another on controversial issues or to teach from a consistent point of view. Nevertheless, it wouldn't take much effort for them at least to know about what their colleagues are teaching, especially in prerequisite courses. They could still teach whatever they preferred, but they could avoid confusing the students and could offer helpful explanations of their disagreements. If you look at the range of attitudes in a large Computer Science department about, for example, agile methodology you're likely to find at least:

You'd surely find similar results for UML, .net, or almost any other controversial tool or technique.

Tailoring the curriculum to market demand

Computer Science and Business Administration are among the few academic departments that tailor their curricula to the perceived preferences and prejudices of prospective employers of their graduates.

We're not so worried about community colleges and junior colleges focusing on Microsoft computer literacy. Students, faculty, and prospective employers understand that's not Computer Science.

More worrisome are distortions of serious subject matter to accommodate some current fad. Today UML2 is at the heart of many such distortions:

Choosing a preferred programming language for elementary and advanced courses has always generated controversy. Faculty members used to argue about how hard it is for beginners to get started with a particular language, how suited the language is for expressing algorithms, or how well the language supports well-structured, highly modular program structure. Today, on the other hand, what counts is perceived demand from prospective employers. Here's an example:

Spring 2001 Announcement from DePaul University School of Computer Science, Telecommunications and Information Systems

Similar announcement that might have been justified (but fortunately wasn't) in 1961 by MIT's Computer Science Department

…Why the switch? "Skills in Java are more marketable," says [a spokesman]3 of DePaul's Information Services. "Lots of companies are large enough to think about how infrastructure will look with Java."

Plus, DePaul CTI prides itself in staying in tune with business. "CTI has a policy to use the language that's being used in industry," says Associate Professor Steve Jost, chair of the undergraduate committee . . . .

"Anyone who wants great mobility in the profession should think about learning Java, [the spokesman] says. "The beauty of Java is that it is not machine specific."

There are no longer prerequisites for Java courses. Students who began their programs when C++ was required will still be able to graduate with the C++ background, but all new students will be expected to study Java.

"Java will be around for a long time," Jost says.

…Why the switch? "Skills in COBOL are more marketable," says Noah Vail of MIT's C.S. Department. "Lots of companies are large enough to think about how infrastructure will look with COBOL."

Plus, MIT prides itself in staying in tune with business. "MIT has a policy to use the language that's being used in industry," says Associate Professor Carzand Cudders, chair of the undergraduate committee. . . .

"Anyone who wants great mobility in the profession should think about learning COBOL, Vail says. "The beauty of COBOL is that it is not machine specific."

There are no longer prerequisites for COBOL courses. Students who began their programs when ALGOL was required will still be able to graduate with the ALGOL background, but all new students will be expected to study COBOL.

"COBOL will be around for a long time," Cudders says.

Of course, using COBOL as a vehicle to teach Computer Science would be unthinkable to nearly all faculty at any respectable school, despite its being "the language that's being used in industry", because COBOL was utterly unsuited both to expressing the subject matter and to organizing large-scale, modular programs. That absurd notion, however, illustrates an extreme result of tailoring a curriculum to the profit motive. That reasoning is based on the assumption, as one former business-school person put it, that "students might more easily justify the tuition reimbursements that support the enrollments. This pressure is hard to resist and starts the schools down the path toward becoming trade schools."

Instructor popularity

In a growing number of institutions the measure of an instructor's teaching competence is the set of students' evaluations—not one of the measures, but the sole measure. At the full-time undergraduate level that rewards the "be entertaining and give them A's" school of pedagogy. Graduate students are more demanding in their evaluations.

What's conspicuously missing is any concern with the students' mastery4 of the concepts and techniques that comprise the course content. An instructor who has a shaky grasp of Systems Analysis may teach System Design or advanced programming instead. The students may find that content interesting and challenging, but they'll emerge with no understanding at all of Systems Analysis.

That's particularly troublesome where one course depends on a prerequisite course. The second course's instructor may have to improvise remedial help for unprepared students, while the first course's instructor may have gotten rave reviews presenting the wrong content.

Such things usually escape the notice of the Department Chair or other administration. Although I'm a part-time adjunct instructor without a PhD, no one responsible for evaluating my performance has ever looked at or commented upon my syllabi, grading policy, examinations, or handout material, nor has any senior faculty member sat in to observe and criticize any of my lectures. (I usually get very good but not rave student reviews.)

Overlooking critical thinking

We often hear that a major difference between American higher education and Asian higher education is that Americans stress critical thinking while Asians stress rote memorization. That may be a valid assessment with respect to teaching history or political science, but my own observations cast doubt on whether it applies to Computer Science.

We fear that the students in the three above examples will be baffled by situations that will arise in their future jobs. I wonder if this is typical of today's Computer Science graduates.

Alumni contact

If faculty members have little contact with one another within an institution and if they don't see colleagues from other institutions at professional meetings, they might still keep themselves informed of what's happening in the outside world by keeping in touch with their alumni. Presumably those who have secured masters degrees have become full-fledged computing professionals who might like to maintain contact with their former mentors. Such contact would yield ongoing benefits both to the graduates and to the faculty.

Alas, that's easier said than done at many institutions.

One well-known institution I'm acquainted with sponsors elaborate quasi-seminars at which alumni can get enlightened on some topic by a faculty volunteer. Depending on the time of day you get a nice breakfast or wine and cheese, but you won't see any other faculty or the department chair. The same institution distributes a quarterly newsletter that tells of all the wonderful innovations taking place, but refuses to publish readers' contributions, not even a letter to the editor.

The future

The trend toward distance learning may make intra-department shortcomings irrelevant a decade from now. As courses get packaged for dissemination over the web, they'll also get standardized for repeated presentation to students who will have no contact with a classroom instructor. The quality of instruction will be in the hands of a small number of specialists. They may manage to avoid today's academic shortcomings, or they may replicate them on such a large scale that improvement becomes impossible.


1 -- Setting up a component library includes establishing an indexing structure, documenting procedures for withdrawal, contribution, and approval, and teaching a secretary or administrative assistant how to maintain it. Individual instructors would be free to require, encourage, or prohibit its use.

2 -- Unified Modeling Language, a collection of largely graphic modeling tools endorsed by the Object Management Group.

3 -- The DePaul spokesman, who played no part in making the choice, asked not to be identified.

4 -- An exception might occur for an introductory course with multiple sections taught by different instructors but with a consolidated final examination. That's more common with, say, introductory calculus than with any Computer Science course I'm aware of.

Return to table of contents
articles on teaching & learning

Last modified October, 2005