What if J. Alfred Prufrock had been a
Computer Science Professor?
An Essay on the Overwhelming Question
of Technical Obsolescence

Robert L. Sedlmeyer
Department of Computer Science
Indiana University Purdue University at Fort Wayne
2101 Coliseum Boulevard East
219-481-6187
sedlmeye@ipfw.edu

I have seen the moment of my greatness flicker,
And I have seen the eternal Footman hold my coat, and snicker,
And in short, I was afraid.

Abstract

I am a 40-something professor of Computer Science, and like J. Alfred Prufrock, I have a bald spot in the middle of my hair. I am feeling increasingly anxious over the possibility of becoming technically obsolete. This fear arises not from a decreasing desire to remain current, but from the increasing realization that there is too much to know and too little time to know it. Worse yet, there is often little rationale for deciding what to learn and painful consequences for making the wrong choice. Is it any wonder that I lay awake at night wondering if Java is just a fad? If every word related to business and communication will be prefixed with "e-"? If all the overhead transparencies that I converted to PowerPoint and then to HTML will become like so much chalk dust with the next delivery technology? So what's a professor to do? Throw up his hands in despair? Seek a positronic brain implant? Or is there a path of graceful degradation?

technical obsolescence (tkn-kl ob`so*les"cence), n. the property of being out of date and not current with skills or practical knowledge in a scientific field.

Let us go now, you and Ito lead you to an overwhelming question. I have fond memories of the IBM 029 keypunch. Let me explain. It was the Spring of 1973. I was embarking on the career I had dreamed about for years: becoming a computer programmer. As an avid reader of science fiction during my childhood, I had become filled with wonder at the possibilities of technologies present and future: robots, spaceships, and yes, computers. While Gort and the Enterprise seemed beyond the reach of my lifespan, HAL, well, that was a different story. Computers were real. HAL was just over the digital horizon. And someday I was going to explore that frontier, to finally go where only my imagination had gone before.

So there I was, sitting at the keypunch, slowly, carefully transforming a stack of 80-column punch cards into a FORTRAN program. I made a lot of mistakes, but after thirty minutes or so I emerged triumphantly from the keypunch room, card deck in hand, with chads clinging like fairy dust to my clothing. It was a magical moment. With great anticipation I handed over my deck to the computer operator. As he walked away I leaned over the small counter and caught my first glimpse of THE computer. It was an IBM 1401. It was nothing like HAL, but it was mesmerizing none-the-less. Lights blinked. Tapes whirred. Printers clacked. And cards shuffled through the reader as if by the hands of a casino dealer. I watched my deck being loaded, and, after a small hesitation, the greenbar listing emerge from the printer. The paper was still warm when I examined the listing. It was full of compiler errors. A character in the wrong column here; a misspelled variable name there; a missing label somewhere else. It didn't matter. I was on my way. A few trips back and forth to the keypunch room and I had successfully written my first program.

That 029 and I became quite close during the next three years. Over the course of the thousands of cards I punched, repunched and overpunched, I discovered marvelous features such as the programmable drum and the DUP key. And the chunk-chunk-chunk of each key press became like a soothing melody (although I must admit that the concerted sound of the keypunch cluster may have adversely affected my hearing more than the rock music of the day). The 029, the 1401, and FORTRAN: from my first tentative DO loops and DIMENSION statements to external sorting, linear programming, and compiler construction, I exulted in the theory and practice of programming with these steady tools.

But nothing lasts forever. The half-life, no, make that the full-life, of computer technology seems to be about three years. When I entered graduate school, I discovered that my expert FORTRAN and keypunching skills were already obsolete. Pascal and PROCSY (Purdue Remote On-line Console System, an acronym that I may or may not have remembered accurately) were the rage. Only Numerical Analysts, the Neanderthals of Computer Science, still used that prehistoric language. Leaving behind the technology I had grown so familiar with was surprisingly simple: I learned Pascal in a few days, combing through the famous Nicklaus Wirth text, and after a session or two with PROCSY I knew I could never punch another card again. I adapted easily to the new technology, my brain still as pliable as a new can of Playdough.

The years passed. I graduated and become an Assistant Professor. Minicomputers arose with accompanying terminal servers. Line editors evolved into full-screen editors. FORTRAN and COBOL did not die as had been expected, and evolutionary niches were found for many other languages such as RPG, Lisp, and PL/I. IBM continued to dominate the mainframe environment with MVS, and DEC had a winner with VMS. Structured programming, soon followed by structured everything a la Yourdon, became the guiding principle in software development.

And I knew them all quite readily, knew them all. Glided deftly from one technology to the next, ever-expanding my reference collection. It was not unusual for me to be teaching courses that used three different languages on different platforms. But I was beginning to notice something strange: Not all of my colleagues were as excited about these new developments as I. In fact, some of the senior faculty had retreated into a small corner of the curriculum; and others seemed unwillingly, or perhaps unable, to modernize their courses, leaving the content grow stale. I couldn't understand their hesitation, and in my youthful insensitivity, did not sympathize with their hidden struggles against intellectual entropy.

More years passed. The microcomputer revolution began. I wrote a grant to purchase three PCs for the Department, but when they arrived they little more than curiosities. A couple of Apple IIs and some other long-forgotten brand (Was it a Northstar Horizon?). DOS entered my vocabulary. I earned tenure. I was promoted to Associate Professor. I was awarded a sabbatical leave. During my leave I became engrossed in applications of AI to electronic warfare, and didn't notice that the world had changed again.

I had an IBM microcomputer on my desk next to my VAX terminal. It ran Windows 3.0. I had no idea how to open up a file or execute a program. This graphical interface was completely foreign to my experience. I had to learn how to interact with a computer all over again. From scratch. To complicate matters, Ada, the language commissioned by the Department of Defense, was now our Department's official language. New hardware. New OS. New programming language. New editors and compilers. And did I mention that the University had just obtained an Internet connection? All of this new technology was very exciting, but demanded that I once again shed, like an old snake-skin, much of what I had known. It demanded that I once again retrain myself.

It wasn't quite as easy this time. Was there that much more to learn? Or was I, like a sopping sponge, less able to absorb any more? I had no time for philosophical reflection, needing every moment to keep one step ahead of my students. I read a lot. I practiced a lot. I sought the aid of my colleagues a lot. Sometimes it wasn't enough. Have you ever had that dream where you sit down to take a test and realize that you know nothing? Sometimes I felt like that when a student would ask a question that I couldn't answer. It was an uncomfortable moment, a humbling moment, a desperate moment. After all, I am supposed to be the expert. And no, I'm not being too hard on myself: I think I should know everything in an introductory programming class! For the first time, I felt vulnerable about my Computer Science knowledge, and had a small, nagging doubt about my competence rumbling around my subconscious.

Not to worry. I eventually conquered Windows, Ada, and the Internet. I regained my old form, but I no longer felt intellectually invincible against the consuming fire of the dragon of technology.

More years have passed since then. Technology has changed radically again. It's now objected-oriented everything, Java everything, and network everything. Advances in all things hardware, software, and, here's a hot term, middleware. Acronyms enough to make a kettle of alphabet soup. And let's not forgot that as technological content has changed so has content delivery. Distance education on the web is the next big thing. Pressure from all sides to create e-courses. And could you include streaming audio and video with that?

I am teaching in a discipline that is moving at warp speed and has more dimensions than "Sliders". I was starkly reminded of this last summer. I do some corporate training now and then, mostly targeting Java developers. I was completing a seminar on design patterns when one of the lead developers asked if I would be willing to teach some workshops on advanced Java programming. He just happened to have a list of potential topics with him. I glanced at the list: Servlets, JSPs, JDBC, JNDI, XML. I knew the "J" stood for Java, but what the heck was all that other stuff? Even in the field of Java technology, I had fallen behind the curve in a very short time. That realization was scary. Very scary.

Which leads me to the overwhelming question: Is technical obsolescence inevitable?

I grow old...I grow old...I shall wear the bottoms of my trousers rolled. Before I answer that question I want to explore what I believe is required to be a technically competent teacher of Computer Science.

Foremost is a firm grounding in the fundamental knowledge of Computer Science. I won't bore you a philosophical treatise on what comprises the fundamental knowledge of Computer Science. Others have wrestled with this question for decades, so I will point you to the thoughtful definition articulated in the evolving ACM Curricula 2001 recommendations [ACM01]. Glass [Glass00]refers to this as state-of-the-art knowledge. I must be able to teach what authorities in the discipline say is important to teach!

Secondly, an understanding of the real world. This is similar to Glass' state-of-the-practice knowledge. There must be a strong connection between the skills taught in the classroom and the skills applied in the workplace. It's fine to be on the leading edge of the technology wave, to anticipate the needs of employers, but it is disaster to allow that wave to wash over me. In the mid-eighty's my Department modified its entire curriculum to focus on Ada. It seemed a logical thing to do since the principal employers of our students were DoD contractors. There was a need and we supplied it. Fifteen years later the DoD rescinded its mandate, and Ada was suddenly an orphan (at least in the U.S.) Though strong pedagogical arguments remained for it use in teaching programming, it soon yielded to Java as our primary language. Why? Simple supply and demand: Java was fast becoming the lingua franca of the Internet and the need for Java developers was exploding. I must be able to teach what employers in the discipline say is important to teach!

Thirdly, adeptness at applying the tools of the trade. You know the old saying, "Those who can, do; those who can't, teach." How about that other one, "If you talk the talk you got to walk the walk." Talking about programming is not enough. If I want to be effective in the classroom, I must be able to build a program. I must demonstrate that I can do what I am asking my students to do. This assures my students that I am not some Wizard of Oz who has nothing behind his curtain of words, helps me to anticipate their problems, and, most importantly, gives me self-confidence. To build programs requires that I know how to use modern program-building tools. During the past year these included Rational Rose, Borland Jbuilder, Microsoft Visual C++, FrontPage, IIS, Explorer and Access, Apache Tomcat, Netscape Communicator, and Oracle. A far cry from the flowchart templates and coding sheets of my first years as a teacher.

I would also include here tools that I use to create and deliver course content. My students are more mobile and more time-starved than ever before. For many of them to be successful, they must have access to course materials anytime from anywhere. The Continuing Studies Department is also interested in leveraging new technologies to expand its offerings to non-traditional students. Today, that means hosting courses on the web. Since I do not have minions of web developers from the Department of Instructional Multimedia Development for Weary Professors waiting to do my bidding, I must create my own content. Of course, this requires another suite of tools. At the moment, these include Microsoft Office, FrontPage and WebCT. Education is a two-way street, so I also extend these tools to include email (I use Novell Groupwise) and products such as Microsoft NetMeeting for supporting more sophisticated interactions. I must be able to teach with the tools that confirm my expertise and conform to students' needs!

In a minute there is time for decisions and revisions which a minute will reverse. So what's the big deal? To fend off technical obsolescence I must keep up with changes in the discipline, the marketplace, and the tools. That doesn't seem so bad. I've been doing it for more than 20 years. How? It's not rocket science. You read. You read some more. And when you're done reading you find something else relevant to read. Then you do. You do a lot. Sometimes you redo what you've done because of something else you have read. Finally, you take what you've read and what you have done and make it palatable for the masses. All it takes is desire, time, effort.

Ah, but therein lies the problem. The desire is still there burning as hotly as ever, but it takes more time and more effort for me to learn and integrate new knowledge than 20, 10 or even five years ago. I am growing old. I am slowing down. Technology isn't.

Actually, the problem is thornier than that. It's not only the speed with which technology is changing, it's the competitive nature of technology. I just realized today that the Java 2 Enterprise Edition is only about a year old. Microsoft has recently introduced the competing .NET suite. And there are the older server-side technologies based on CGI (perl, php, etc.) Will one technology dominate or will there be an unpeaceful coexistence? Even a dominant technology today could be replaced tomorrow.

And should I then presume? And how should I begin? Faced with dwindling intellectual efficiency technical obsolescence may be inevitable for me and it may be hastened by an inopportune choice of what technologies to pursue. So what should I do? Should I simply deny what's happening and blissfully head for the technological abyss? Should I throw up my hands in despair? Should I, like Prufrock, retreat into the depressing loneliness of "a pair of ragged claws scuttling across the floors of silent seas" awaiting the end? No. As a colleague mine often said, "We are engineers. We solve problems." Here's my solution to this dilemma, or the top six ways to ensure graceful degradation.

6. Accept your limitations. I love to play basketball. I was never the fastest or tallest player on the court, but I hustled. As a result I often got loose for a fast-break basket. Twenty years later, I still love to play basketball, but I can no longer beat anybody down the court. I still play hard, though not as long, and contribute with my defensive hustle. Adjusting my game to my physical limitations has allowed me to continue to play, and enjoy basketball. I believe the same is true for teaching Computer Science. When I was younger I knew a lot more about a lot more. I no longer have enough time or energy to keep informed of all the technological advances. But I take solace in the fact that I still know a lot about some things, and some about a lot of things. I still enjoy learning and exploring new technologies while limiting my scope of interest. As for the rest, well, I can leave that to others; I no longer feel I have to know everything to contribute something.

5. Read. I've always done this. It's one of the simplest ways to find out what's hot and what's not. I try to read at least one article every day from either a trade publication or academic journal. And I constantly review textbooks for subjects I teach. It's the most practical way to cull the most important recent developments and which technologies are on the most solid ground.

4. Let your students teach you. There always seems to be a subset of majors who are more curious, more motivated, and more intellectually endowed than the rest. Use them to your advantage. Sign them up for a directed studies course on a topic of mutual interest. Give them the responsibility to become the expert and demonstrate their expertise to you through appropriate papers, presentations and projects. I have found this to be an effective means to learn about a single technology, such as JavaServer Pages.

3. Keep one foot in the real world. Look for consulting opportunities, preferably those that allow you to apply rather than teach computer science knowledge. It is not always easy to leave the relatively safe confines of the ivory tower, but it is always rewarding. Rarely have I taken a consulting position that didn't demand learning some new technology or some technology more intimately. For example, I have had a long-term relationship with a local ISP. In the beginning, I reluctantly, and with much trepidation, took on the duties of a system administrator. It's one thing to teach about networking; it's another to actually configure and troubleshoot networks. My theoretical understanding served me well, and I picked up invaluable practical knowledge that has enhanced my classroom. I now look forward to each summer for the challenge of the next real world opportunity.

2. Work smarter. One of the most valuable lessons I've learned as I mature is that I don't have to do everything myself. There are plenty of resources available to support my teaching responsibilities. The two I have found to be the most valuable are book publishers and the Internet. The quantity and quality of ancillary resources for Computer Science textbooks has improved tremendously during the last decade. Where before I was fortunate to have an Instructor's Manual and test bank I now can obtain almost everything my heart desires: sample programs, PowerPoint slides, laboratory manuals, and Internet links. And speaking of the Internet, I have discovered a wealth of tutorials and sample programs for almost every course I teach. On occasion, I have even found a kindred soul who is teaching very similar content and has placed all his/her materials on the web. (Yes, there are copyright issues to resolve in order to use this strategy. I am confident you will find great cooperation here!) Using these materials, I have more time to focus on course content rather than delivery, and therefore, more time to learn the next new thing.

1. Do few things, but do them well. St. Francis of Assisi gave us this wisdom to live a happy and fruitful life. Given my limitations, I will only become frustrated if I try to know too much or do too much. I must realistically assess what dogs in the Computer Science pack I can run with and then focus my training there. I may teach a smaller set of courses. I may use a smaller set of tools. I may let my more youthful and ambitious colleagues shoulder more responsibility for course and curriculum development. Whatever I choose to do, I will do with the same enthusiasm, commitment, and desire for excellence as I have always done. And that will lead to a happy and fruitful professional life.

And indeed there will be time to wonder, ' Do I care? ' and, ' Do I dare? ' . I have mused long and thoughtfully over my plight, the dreaded specter of technical obsolescence. And over these many words I have given you a glimpse of my personal journey. I would hope that you found something familiar, a partial reflection of your own experiences. I certainly care about my diminished ability to keep current. It is an uncomfortable feeling. But unlike poor Prufrock, I have not been paralyzed by indecision into doing nothing for fear it will be the wrong thing. I have a plan. It may not be a perfect one, but I think it is a good one. Only time will tell. If things don't work out, well, there's always golf.

REFERENCES

[ACM01] The Joint IEEE Computer Society/ACM Task Force, Chapter 5, Computing Curricula 2001, http://www.computer.org/education/cc2001/ironman/cc2001/v2-overview-bok.html.