Sadly this turns out to be an increasingly poor match with the marketplace. Consider an employer with a big stack of well-defined clearly specified problems to be solved. That stack of problems is ideal for handing off to programmers in a low-wage country on the other side of the globe.
Top graduates from a standard Computer Science undergraduate program are well-prepared to go on to graduate school in Computer Science and ultimately to become professors of Computer Science themselves. In other words academics are doing a fine job of replicating themselves. But the majority of graduates will be looking for jobs as software engineers and the focus of this article will on how best to prepare people for those jobs.
Graduates haven't done much group work. Universities spend $billions on facilities so that students can sleep together; $0 on facilities so that students can work together. We have a society that, at least to judge by the prescriptions written by pediatric psychiatrists, is suffering an epidemic of Attention Deficit Disorder. We have students who watched MTV in their cradles. Yet we structure learning so that students take homework back to their dorm rooms and try to work on problems by themselves while fighting off distraction from dormmates in unrelated majors, TV, DVDs, video games, instant messages, email, and the Web. Students who come to the university with pre-existing excellent study habits will still get an excellent education. Students who managed to hop over the low hurdles of junior high and high school despite poor study habits may get minimal benefit from college.
Graduates are not good at taking vague goals from a non-technical person and turning them into concrete specifications that can be implemented within a fixed budget of time and resources.
Graduates are not good at communicating (writing, presentations, asking questions of users and customers).
Lack of experience with user interface design and testing and no experience handling real users' suggestions, complaints.
Lack of professionalism, i.e., graduates are not dedicated to completing something of value to end-users. Students learn to feel good about themselves when they solve well-specified problems and get something for themselves, usually a good grade. Students do not learn that value is generated only when the first end-user accomplishes a task with the new information system. Consequently most CS graduates are happy to draw a salary for building a system that is 90 percent finished but never installed or used.
Lack of focus on big picture; graduates can't understand how their work relates to larger organizational goals.
Graduates are not very experienced with quickly making sense of large commercial tools and libraries and writing small pieces of code that control or extend those libraries. The result is a tendency to start from scratch or rewrite code that is not fully understood rather than reuse. Many early Web applications were plagued with bugs from half-tested database management systems written by computer science graduates who were more interested in writing C code than in learning to apply standard relational database management systems.
The news articles are correct but not complete. While it is true that U.S. employment for software development has shrunk and hundreds of thousands of people are being fired it is also true that hundreds of thousands of people are being hired. The newspapers are correct in that number of people hired has been smaller than the number fired. The question that journalists haven't asked is "Who is getting fired?" For nimble employers the first people to get pink slips are older programmers whose performance is average but whose salaries and benefits costs are high. Who is getting hired? New college graduates, thanks to youth, have a high energy level and low employment costs. Among those desirable young relatively cheap workers the ones who get hired first will be those whose education matches current employer needs.
For the foreseeable future, every young person graduating in Computer Science who gets a job in the United States will owe his or her career to the firing of an older worker. It is a cruel marketplace but our task in this document is to improve computer science education and help young people, not to reduce cruelty in the American employment market. Thus our goal during a computer science bachelor's program ought to be to give a young energetic person the open-ended project and group work experience that the best older programmers have.
Second, we want our graduates to have satisfying careers where they have autonomy, responsibility, and job security. Consider the typical computer programmer who takes specifications for a subsystem from a manager, unthinkingly produces a program to meet the spec, and hands the resulting code back for testing, integration, and evaluation by other departments. This is really a factory job where the workers' hands don't get dirty.
What's wrong with that? Sociologists have tracked a substantial loss in worker satisfaction as craft jobs were replaced by factory jobs. A craftsman builds a complete product and delivers it directly into the hands of a customer, seeing and hearing the satisfaction that the new product delivered. A factory worker, by contrast, builds a small component of a product and is typically several distribution layers removed from the customer.
A craftsman is responsible for whether and when a product goes out the door to the customer. In a classical factory a totally separate part of the bureaucracy, the quality control department, decides whether or not a product should be shipped. A craftsman listens to customer needs and adapts the resulting product accordingly. Factory workers never talk to customers; a separate marketing department assesses customer needs and determines changes in product design. Not only is a job in a code factory not very satisfying it is neither very secure.
There is a near-perfect abstraction barrier between the manager and the programmer: specs in, code out. One of the things that students learn as computer science undergraduates is the virtues of abstraction barriers. You can replace Module A (expensive programmer in the U.S.) with Module B (cheap programmer in another country) and never notice as long as Modules A and B present the same interface to the outside world (email specs in; source code out).
What actual skills will a graduate need in order to get a job? To get a satisfying job? To keep a job in the face of pressure from younger and/or cheaper workers?
A professional programmer ought to be able to pick worthwhile problems to attack. Engineering is the art of building cost-effective solutions to problems that society regards as significant. A person who blindly does what he or she is told, without independently figuring out the context and significance of the problem, is not doing engineering. A professional programmer needs to be able to sit at a meeting with decision makers, prepared with substantial domain knowledge, and make significant contributions to the discussion. A professional programmer needs to be skilled at clean-sheet-of-paper designs.
Our students should be able to study 48 weeks per year, perhaps in four 12-week quarters, and finish their bachelor's degree in 30-36 calendar months. Most universities operate in most respects as copies of Ivy League schools. In many ways it makes sense to copy leaders such as Harvard and Yale but the calendar isn't one of them. Top universities in the United States are only in session for 26-28 weeks. It makes sense if the customers are wealthy families. There needs to be a long summer break so that the kids are free to join the family on its yacht in the Mediterranean. And there needs to be a long winter break so that the kids can come down to the beach house in the Caribbean tax-haven. And what fun is spring skiing in Aspen if Biff and Muffy can't take a week off from school?
Computer science, however, is not a commonly chosen major for children of the American aristocracy. For a middle class parent the traditional university calendar means that not only do they have to pay tuition but they also have to pay for the spring break trip to South Padre Island and, in a world where summer jobs are scarce, support the kid through long summer and winter breaks. Why not have Johnny, Jr. in school on a more-or-less full-time basis so that he graduates and is off the family payroll by age 20?
Students should graduate with a portfolio of work and credentials to show employers. Nearly all programmers think that they are above average in talent and achievement. Precious few have any concrete evidence to support this belief. The curriculum needs to include enough open-ended projects and time for producing good write-ups and presentations that every student graduates with a portfolio showing what problems were attacked, what designs were produced, and to what extent a complete solution was implemented. The curriculum should also provide opportunities for achieving recognized national certifications. As of the date of this writing the most common certification standards are from Cisco, Microsoft, and Oracle and are too closely tied to those companies' products for most academicians' taste. Unless and until a consortia of universities and employers develops a competing set of standards it is probably worth helping students meet the currently recognized standards.
Grade inflation is so rampant at most good schools that a transcript is no longer meaningful. Students should be graded exclusively by outsiders. In some cases it will be a computer scanning the results of their Microsoft certification test. In some cases it will be an external client for whom a student team has built a project. In some cases it might be professional engineers or academics in a low-wage foreign country applying written standards. But in no case should it be a teacher whose salary is being paid by the student's tuition. The potential for conflict of interest and therefore grade inflation is too high and furthermore we want the faculty to be regarded as coaches rather than evaluators.
All student work should have the character of an engineering project: client talks about a problem; student team prepares a written plan for solving the problem; student team discusses the plan with the client; student team builds a prototype; student team tests the prototype with the client and users; student team refines the prototype in response to the testing; student team documents its results. Everything in a standard engineering curriculum can be taught with this process. For example, students building a flight simulation game might need to refer to a Physics textbook and do some practice Physics problems in order to learn enough to build their prototype. This makes it a bit tough for the faculty, who need to be clever enough to weave such courses as Physics, Calculus, and Biology into engineering projects. The payoff is that by the time the student graduates he or she will be completely comfortable with the engineering process of listen, design, discuss, implement, test, refine, and write up.
Weaving such subjects as literature and history into the curriculum present more of a challenge and are left as an exercise for the reader :-).