part of Teaching by Philip
Greenspun; mostly written in 2004
The standard American university undergraduate computer science
curriculum and teaching methods are essentially unchanged since the
mid-1970s. One interpretation of this stasis is that the ancients
achieved perfection and therefore there is no room for improvement of
current graduates. Evidence against this interpretation comes from
employers, who are so dissatisfied with their U.S.-educated IT
workforce that they are shipping jobs overseas as fast as is
practical.

What's right with graduates of a standard U.S. CS program?

One thing that recipients of a U.S. bachelor's in Computer Science are
good at is doing problem sets. The new graduate has had four years of
experience in tackling well-defined clearly specified problems that
have been broken down into small tasks.

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.

What's wrong with graduates of a standard U.S. CS program?

Graduates haven't done much open-ended project work. Consequently
graduates may fall prey to the following failures: (a) Attractive (to
the designer anyway) internal design that is too complex to implement
within time constraints; (b) Overly brittle and hard-wired designs
that can't be extended in response to changing requirements.

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 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.

What do we want graduates to be able to do?

First and foremost we want our graduates to be able to get a job. A
college education is a significant investment for most families and,
unless they are rich, they need to get a return on that investment.
If you follow the news you might think that it would be impossible for
a young recent computer science graduate to get a job. The IT
industry overall is shedding jobs in the U.S., with as many as 30
percent of total jobs lost between 2000 and 2004. To the extent that
new staff are hired it sounds as though they are all being hired to
work in Third World countries.

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.

Some Ideas for a 21st-Century Undergrad Computer Science Program

Students come to work in a permanent lab setting, rather like a
corporate open-office maze of desks and dividers. A student who is
stuck can therefore draw on help from surrounding students and from
roving teaching assistants. Note that this plan is for a school that
specializes in teaching computer science and therefore if two students
are in the same year it is virtually guaranteed that they will be
taking the same classes.

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
:-).