bed early in the morning and headed off to the then-extant Harvard Aiken Computation Laboratory to write and debug code, I found myself the sole user of the Harvard PDP-10 research time-sharing computer. This was my reward for getting up before 5:00 a.m.

The PDP-10 ran at roughly 400,000 instructions per second. It had less than half a megabyte of memory and a few megabytes of disk storage; we used small magnetic tapes, called DEC tapes, for all long-term storage. Even in that early era, the Harvard PDP-10 was networked with a few other computers via the ARPANET, the predecessor of the Internet. In fact, in my work I regularly accessed computers at MIT and Carnegie Mellon. At the time, I didn’t know how much the PDP-10 cost. However, I did a little research for this presentation, and I believe that it would have cost about $2 million in today’s dollars.

In addition to pursuing my debugging work, I remember my mind wandering and contemplating my career options. At the time, I was considering going into economics and journalism, but I was also thinking about computer science. That early morning I do remember explicitly thinking about the comparative advantage I had as a student at a U.S. university, capitalized by my very own PDP-10 (at least at 5:00 a.m.), and thinking about all the folks in Europe who had minimal computational access (note that Europeans used to do much less hands-on computer science because of this). At the time, I never even considered India and China as having any software capabilities. I believe my unquestionable comparative advantages impacted my career choice.

Almost 35 years later, the contrast is clear. Modern computation and networking are four to five orders of magnitude better, cheaper, and more ubiquitous than they were then. And most necessary information is on the Web. Take just one example: MIT’s plan to put most of its instructional materials on the Worldwide Web. Even machine translation is making some progress making information available in multiple languages. Thus leveling of opportunity is undeniable.

This leads me back to my first observation. A U.S. student going into the field of computer science today does not have as great a comparative advantage as a student even 10 years ago. This is not a reason to avoid computer science and software, but it is important to recognize that the U.S. advantage has decreased.

The second point I want to make is that “software” or “information technology” is not one large, coherent, aggregated profession, but is instead a very diverse field. This is partly because it is a very big field—more than a trillion dollars are spent on software worldwide (in aggregate). To illustrate this diversity we can look at four different “cuts” across the variety of activities in and around software (Figure 1).

The first cut considers software from the vantage point of software production. Here are some aspects of the process, although not all of the elements I’ve listed are applicable to all software production:

• conceptual work as a basis for deciding what can and should be done

• competitive analysis to determine how to succeed in the market

• work on requirements as a basis for making a formal decision about what a program must do

• various perspectives for considering the design of a system:

  • the human interface

  • the security of operation

  • the robustness of operation in the presence of faults

  • other factors

• development of the high-level design of the major modules and information structure of a program

• the low-level design of individual modules

• coding

• porting to alternative platforms

• formal and informal verification

• testing of components, modules, and systems

• evaluation and tuning of performance

• intellectual property protection and licensing

• development of documentation/information and national language support

• packaging and delivery

• project management

Undoubtedly, many more activities could be added to this list.

The second cut across the field, the application domain of software, influences development processes in many ways. Systems software (e.g., operating systems, database management systems, server infrastructure, middleware) that run continuously have different requirements, such as robustness and scalability, than tools that are executed and re-executed periodically. Packaged applications that are sold to numerous customers have different requirements (e.g., significant expertise requirements in the huge number of potential application domains) from programming tools, although they must still be of use to a variety of customers within a particular industry or problem domain. Custom applications for one or a few uses or customers may be considerably easier to develop because they require less generality, and there is, therefore, less of the combinatorial explosion that makes packaged software so expensive. These different types of applications also require significantly different production methodologies.

Even in each of these application areas, there are many approaches to developing software:

• The traditional waterfall method is a common baseline,