(revision of invited eitorial, ACM SIGCSE Inroads, June 1999)

Michael B. Feldman
Professor, Department of Computer Science
School of Engineering and Applied Science
The George Washington University
Washington, DC 20052


"Hook 'em with a quote," my writer wife advises me. "Draw them in with an anecdote." By the "more is better" theory, I'll try to draw you in with four anecdotes. As the humorist Dave Barry would put it, I'm not making this up.


Summer 1965. I think I contributed to the Y2K problem. After my junior year in a BSEE program, my first "real" summer job (camp counselor didn't count) landed me in a local branch office of a large (very large) computer company. I was an intern attached to a sales team, learning to specialize in customer applications while the salesmen specialized in mainframe configuration and pricing.

My prior computing experience consisted of one 3-week Fortran project in my numerical-methods course. When I returned from a mandatory 2-week crash course in the assembler language of the era, the salesmen unburdened themselves of a pesky intern by parking me at a large state agency, suggesting to the data processing manager that I was there to help him. I assume they didn't tell him I was just an intern; he put me straight to work designing and coding a module of the agency's new payroll software. I knew just enough about software development to be really dangerous to someone's business. For all I know, my code is still running there, with 2-digit year fields, in emulation mode, computing incorrect overtime payments.

Fall 1975. In my first semester as a green assistant professor, I was assigned to teach a sophomore assembler course. To one non-degree student in the course, I suggested that perhaps a vendor-sponsored short course might serve her needs better than a curriculum-based one. This was not possible: the employer would reimburse tuition only if the course carried academic credit.

The student earned a "mercy C." Shortly thereafter, my stern-faced department chairman showed me a blistering letter from this student's supervisor. No employee of his would ever enroll in another of our courses. I had focused too much on designing assembler programs, algorithms, number representations, and so on, and had thus failed to cover the entire System/360 instruction set. Trembling, I explained that I had followed the advertised course outline. The chairman grinned and ripped up the letter. "Don't worry, Mike; you did the right thing. We are educators, not trainers. The employers don't get it."

Summer 1988. A friend managed the division that educated software developers who were using his company's compiler and CASE tool products. The company decided to change his division title from "Education" to "Training." (They changed little else, just the name.) The division's business picked up. A survey revealed that their customers perceived "training" to be useful, while "education" was "academic" and therefore useless.

Spring 1998. A technical manager from a large (very large) software company visited my department. He was recruiting graduating seniors himself because he didn't trust Human Resources to find him the best people. For 45 minutes, he treated me to a withering critique of our program. We focused too much attention on "engineering" (his word) and not enough on how to make software "really fast." He was unlikely to hire any of our graduates; he was not looking for "engineers"; he needed a few "brilliant hackers."

My stories span 34 years; our technologies have changed immensely in that time. The 1965 mainframe cost millions, had punched-card input and a 32k core memory, crashed several times a day, and lived in an isolated air-conditioned room, cared for by lab-coated technicians. My current PowerBook regularly runs MacOS, Windows, and X GUIs and applications at 200MHz clock speed. It fits in my briefcase with room to spare, and cost (in constant currency) roughly the same as the tuition for that 1975 student's one GW course. Computers are no longer isolated batch processors; they so pervade our lives that much of society is in panic over the predictions of disaster next New Year's day.

And yet in some ways nothing has changed. Computer science education is booming, yet we read news articles about self-taught high-school kids who say they can make it in this field without college degrees. Employers hire them, too, which tends to prove them right. Our own image of computer science often seems light-years away from industry's image of our field, and the image gap has not closed much in three decades. What's going on here?


"Our field is new and constantly changing," we tell each other. Well, yes, but anything that's fifty years old is no baby. Our technologies are constantly changing, but deep down perhaps we can find some invariants.

Perhaps we've been using the "new and changeable" argument as an excuse to sidestep the question of how to define ourselves as computer scientists and as computer science educators. We must articulate our mission more effectively to our students and their employers, if we are to convince them that a graduate of our four-year program is significantly better than the typical self-trained high-school kid.

I maintain that computer science is a profession. My American Heritage Dictionary CD-ROM says:

"pro-fes-sion n. 1. An occupation requiring considerable training and specialized study: the professions of law, medicine, and engineering. 2. The body of qualified persons in an occupation or field: members of the teaching profession. 3. An act or instance of professing; a declaration. 4. An avowal of faith or belief. 5. A faith or belief: believers of various professions."

I think CS meets all five of these definitions. I'll focus on the first two here and return to the others shortly.

Most of our CS students see their college study as direct preparation for employment. This they have in common with engineering, business, medical, and law students. In contrast, my younger son is majoring in English literature. Like most liberal-arts students, he is confident he'll find gainful employment, but has few illusions that his job will stem directly from college courses.

Aside from all my majors, I am advising a growing number of students who are minoring in CS. Many of them are pre-meds. When I express my joy at how computer-savvy tomorrow's physicians will be, they usually answer, "It's simpler than that; I want to have a fallback in case I don't get into medical school." Don't you love the refreshing candor of the Generation X-ers?

Friends who teach in liberal arts-based CS programs often claim their programs are not professional. I think they may be deluding themselves: Whatever they claim, their students are studying CS because it will get them a job! (OK, OK, some of them are headed for graduate school, but that's because they think two CS degrees will get them a better job than just one.)

Like it or not, then, our students are heading for a profession. But what profession? As far as I know, the only definition of CS with even a rough consensus is this one:

"...[T]he discipline spans both advancing the fundamental understanding of algorithms and information processes in general, as well as the practical design of efficient reliable software and hardware to meet given specifications... In computer science there is an inherent intermingling of the theoretical concepts of computability and algorithmic efficiency with the modern practical advancements in electronics that continue to stimulate advances in the discipline. It is this close interaction of the theoretical and design aspects of the field that binds them togeher in a single discipline.

"...[A] well-educated computer scientist should be able to apply the fundamental concepts and techniques of computation, algorithms, and computer design to a specific design problem. The work includes detailing of specifications, analysis of the problem, and provides a design that functions as desired, has satisfactory performance, is reliable and maintainable, and meets desired cost criteria. Clearly, the computer scientist must not only have sufficient training in the computer science areas to be able to accomplish these tasks, but must also have a firm understanding in areas of mathematics and science, as well as a broad education in liberal studies to provide a basis for understanding the societal implications of the work being performed."

The more I read this "mission statement," the more I think it describes who we are, what we do and how we should educate. Its precepts are invariant to technological fads. I wonder if we could all agree on it. When I've tried to open a discussion of this definition on the SIGCSE members listserv, I cited its source as CSAB [CSAB 99], and the thread was thus diverted into a discussion of the merits of CSAB accreditation per se. I'm not lobbying for accreditation here, just for adopting that definition of our profession. It's the best definition we have!


The last three parts of the dictionary definition of "profession" focus on embracing "religious" tenets -- articles of faith that are neither proved nor refuted.

In describing our debates about technical matters, we use terms that evoke evangelism, religious wars, crusades. With no disrepect to my Muslim colleagues, I observe that I've heard the term "jihad" bandied about in CS education circles. Computer folks do have a natural tendency to use wry humor and hyperbole, but there's some truth in this description.

David Kay (Kay 1996) has written eloquently in these pages on "bandwagons" (a more polite term than "crusades") in CS education. The current primacy of the "object-oriented paradigm" in first-year CS education is the most recent example. I'm not taking sides here on the merits of O-O; rather, I point out that we have neither proven nor refuted that teaching it in our intro courses "works" better than other approaches. We accept it on faith and come too close to labeling dissenters or skeptics as heretics.

Indeed, we don't even try to prove these things. If we were trying, for example, to validate the O-O paradigm in first-year courses, we'd see lots of empirical research comparing different course approaches, carefully following successive cohorts of students through four years, developing metrics to help us conclude whether one or another approach prepares them more effectively for their profession. SIGCSE conferences would have multiple sessions on it; "dueling studies" -- two studies showing opposite results -- would cry out for replication to sort out the contradiction.

In fact, we don't see much research of this genre. In many institutions, such research -- empirical research in general -- is labeled "outside the mainstream of computer science" and therefore not rewarded with promotion, tenure, and collegial respect. As one who's directed a half dozen empirical dissertations and sat on committees for nearly a dozen others, I can attest to the difficulty of such research. But how can we afford not to do it? We can only hope to be credible to our friends in industry if we are willing to subject our beliefs to rigorous controlled study and peer review, and to reward those who do the studies.

A colleague at another university told me his faculty had debated some sweeping lower-division curriculum changes. The arguments pro and con were "religious." The first vote was a draw, with one abstention. After some animated hallway discussion, a second vote was held. The abstainer voted for the changes, and the changes were implemented. None of those pushing for the change were willing to teach the new courses. My colleague, downhearted, asked me how I'd like teaching in a department that was so rancorously divided on curriculum matters. One wonders how the students there must feel!

This may be an extreme case, but it's indicative of our collective lack of consensus on important things, and especially on curricular matters. I'm idealistic enough to believe that we can do better, and that some solid research would help us immeasurably in doing so.


Our flesh-and-blood lives depend on computers. Recently a major auto manufacturer recalled a very large number of cars to upgrade the software ROMs in their airbag computers; a number of bags had deployed when the cars merely ran over potholes. Was the code buggy? Correct with respect to buggy specs? We don't know, of course, but the result was an unpleasant surprise to a number of drivers. Someone's former students wrote the old, and the new, versions of that airbag software.

On an icy Maryland hill in February, when I press firmly on my car's brake pedal, I entrust my life to its antilock system. Should I have to worry that my ABS computer isn't running the latest software patch? Someone's former students will be writing tomorrow's ABS software.

Our businesses' lives depend on computers too. Continuing with the car example, a mechanic's work comes to a screeching halt if a storage leak in the database manager freezes the PC when he looks up a front suspension system on the service-manual CD-ROM. The mechanic can't order a replacement water pump if the computer in the parts warehouse has crashed. The customers get impatient if they can't pay their fuel or repair bill because the credit card network is down. Someone's former students are developing the databases and the network software.

Our students should aspire to do important things, to contribute to making the world just a bit better through computing. As educators in computer science, we must therefore inspire our students to aspire to develop critical systems; our systems are, in fact, all critical.


Let me briefly describe my CS1 course, "Introduction to Software Development." This course has no prerequisites; 75-80% of its students are in the second semester of the CS and Computer Engineering majors. [Feldman 99a]

It is simply not true that most students have done programming in high school. Asked in a survey form at the start of the course to "briefly describe any programming experience you have had before this course," fully 50-60% of the students claim no prior experience. This number has been stable for at least the last five years.

There's a strong emphasis on life-cycle documentation using the Koffman case study model [Feldman 99b]. Equally strong is the stress on testing plans. Projects -- due every week or two -- are taken from numerical, information-processing, and simulation domains.

The final project this semester simulates a highway speed survey in which "cars" arrive at random intervals, traveling at random speeds. Their speeds are displayed in very large digits; this emulates those trailer-mounted huge displays the police use to warn us that we're speeding.

This project -- and the ones leading up to it -- involves concepts from graphics (the large digits are treated as a "font" that is displayed using a simple coordinate transformation), file management (the "font" is loaded from a file and the arriving cars' statistics are logged to a file), real-time systems (if a "car" arrives three seconds after the previous one, the program waits three seconds before displaying the new speed), and simulation (we could replace our car-arrivals package with a physical radar unit).

Technical "mantras" in the course:

  1. Every object--even a scalar one--has a well-defined set of values, in a range that is natural to the application, with a well-defined set of valid methods.
  2. Software should behave predictably for any plausible input values, not just for "correct" ones.
Psychological "mantras":
  1. Inexperience is not equivalent to stupidity. There are no "stupid questions".
  2. This is not a "filter course". Our goal is that you should succeed in it. If everyone earns an A, everyone will get an A.
I and my graduate TAs answer a lot of e-mail from students. They send listing files with interwoven compiler diagnostics, and we supply hints on correcting their errors. This system of "virtual office hours" allows students to ask questions asynchronously, often very late at night, and gives us priceless feedback on the kinds of errors beginners really make. Once the students realize we're approachable, they start e-mailing us about advising issues, career choices, and other matters.

The grade profiles are interesting: While the top few students are generally "experienced", and the bottom few are generally "inexperienced", the great majority of students are distributed up and down the same curve, regardless of experience. The few who fail are completely clueless or completely negligent, or both.

About 75-80% of the students typically remain through the final exam. It's hard to find reliable retention data from other institutions, but I did hear that the retention in a similar CS1 course at another local university is 50% or less.

This gratifying data tends to support my claim that a carefully designed CS1 course, coupled with a very beginner-friendly compiler and knowledgeable, enthusiastic, and approachable instructor, can be challenging and interesting to students with and without experience, and can "hook" them on doing important things. It draws them into the major and, generally, keeps them in the major.

My colleague who teaches the senior capstone course is neutral in the language and paradigm wars. The student-designed senior projects are, for the most part, exciting and sophisticated, using the latest hot tools and techniques. My colleague interviews his graduating seniors extensively; their consensus is that the CS1/CS2 sequence is doing the right stuff, the right way, with the right language (Ada 95). "You should teach -- and we should learn -- lots of languages, tools, and systems," our seniors tell us, "but Ada 95 is definitely the best way to start."


My nephew invited me to his "white-coat ceremony" of induction into the first year of medical school. What impressed me most about this rite of passage was that the students' white coats symbolize their membership in the profession, not after they graduate, but from the start. Under the eye of older, more experienced members, they are expected to become ever more expert at the technical aspects of medicine, but also always to act as the professionals they are, always showing unassailably ethical behavior in dealing with colleagues and patients, always ready to recognize their own limitations. My nephew came away inspired; he knew his work would be both a joy and challenge. Important work.

Our first-year undergraduates don't have quite the perspective that medical students do after four years of college, but maybe we can still invent analogues of the white-coat ceremony in our first-year orientations. I'd love to have a SIGCSE discussion of how we could make our entering students feel a part of an honorable profession, ready to undertake the joy and the challenge of our important work.

Throughout the curriculum, we must educate our students for a career, not just train them for a summer internship, coop, or first job after graduation. We must teach them how to distinguish the truly new from the old wine in glitzy new bottles. We must demonstrate the relevance of our material to the profession, and its importance to the world. In this era of ever more pervasive computers, we must inspire a sense of pride in craftmanship, in correct code, in courteous program style, in usable documentation. We can do this; we must do this. Our students are relying on us, and after they graduate, the world will be relying on them.


[CSAB 1998] CSAB, Computer Science - the Profession,

[Feldman 1999a] Feldman, M.B., CSci 51, Introduction to Software Development,

[Feldman 1999b] Feldman, M.B., and E.B. Koffman, Ada 95 Problem Solving and Program Design (3rd edition, ISBN 0-201-36123-X), Addison-Wesley-Longman, 1999,

[Kay 1996] Kay, D.G., Bandwagons Considered Harmful, or The Past as Prologue in Curriculum Change, ACM SIGCSE Bulletin, vol. 28, no. 4 (Dec. 1996), also online at