Article

The Future of Programming

Anthony I. Wasserman
University of California, San Francisco
Steven Gutz*
Digital Equipment Corporation

The nature of programming is changing. These Introduction

changes will accelerate as improved software develop-
ment practices and more sophisticated development tools It is well-recognized that software is the dominant
and environments are produced. This paper surveys the cost in the development of computer systems. For many
most likely changes in the programming task and in the systems, software represents 80 percent or more o f the
nature of software over the short term, the medium term, total system development cost [6] and there are indica-
and the long term. tions that this figure will continue to grow as hardware
In the short term, the focus is on gains in programmer costs continue to drop. 1 Computing is a labor-intensive
productivity through improved tools and integrated de- industry, and the number o f programmers is proliferating
velopment environments. In the medium term, program- as attempts are made to automate a wider variety o f
mers will be able to take advantage of libraries of soft- applications. The result is a very sharp increase in money
ware components and to make use of packages that being spent on software, an increase further stimulated
generate programs automatically for certain kinds of by the cost of maintenance and enhancement of existing
common systems. Over the longer term, the nature of systems.
• programming will change even more significantly as pro- This trend cannot continue indefinitely. There is
grammers become able to describe desired functions in already a serious shortage o f skilled programmers and
a nonprocedural way, perhaps through a set of rules or the cost o f such a person is expected to surpass $100,000
formal specification languages. As these changes occur, a year (salary, benefits, overhead) by the mid-1980's.
the job of the application programmer will become in- There is clearly a need to gain control over these rising
creasingly analysis-oriented and software developers will costs and to make programmers more effective.
be able to attack a large number of application areas At the same time, it is necessary to work toward
which could not previously be addressed effectively. improved software quality. Quality refers not only to
reliability and correctness but also to ease of use and
CR Categories and Subject Descriptors: D.2.2 [Soft- maintainability. One key objective is to provide pro-
ware Engineering]: Tools and Techniques--programmer grammers with tools and techniques that can improve
workbench, user interfaces; D.2.6 [Software Engineering]: both the process o f software production and the quality
Programming Environments; D.3.0 [Programming Lan- o f the resulting software. An equally important objective
guages]: General; D. 1.2 [Programming Techniques]: Au- is to provide users, many o f whom are unfamiliar with
tomatic Programming; K.7.0 [The Computing Profes- the technical details of computer systems, with systems
sion]: General that make the computer a useful tool.
General Terms: H u m a n Factors, Languages Efforts to attain these objectives must take a variety
Additional Key Words and Phrases: integrated de- of forms. Some efforts will be relatively minor, aimed at
velopment environments, software development meth- the short term and at incremental improvements in the
odology, prototyping, personal development systems, software development and evolution process. These ef-
software components forts will focus primarily upon the development of indi-
vidual software tools and the reduction of programmer
* This paper presents the opinion of its authors, which is not support costs. Other efforts will be less immediate and
necessarily that of Digital Equipment Corporation. Opinionsexpressed
in this paper must not be construed to imply any product commitment will aim at changing the nature o f programming and
on the part of Digital Equipment Corporation. providing sophisticated environments for the individual
Authors' Present Addresses: Anthony I. Wasserman, Universityof programmer and the software development organization.
California, Section on Medical Information Science, Room A-16, San
Francisco, CA 94143; Steven Gutz, Digital Equipment Corporation,
Maynard, MA 01754.
Permission to copy without fee all or part of this material is
granted provided that the copies are not made or distributed for direct t An important exception to this statement is the area of micropro-
commercial advantage, the ACM copyrightnotice and the title of the cessor-based systems, where the resulting "embedded" system is rep-
publication and its date appear, and notice is given that copyingis by licated thousands of times. In that situation, the total hardware cost
permission of the Association for Computing Machinery. To copy may dominate the software costs but the criticality of producingcorrect
otherwise, or to republish, requires a fee and/or specific permission. and reliable software is even more important than in traditional
© 1982ACM 0001-0782/82/0300-0196 $00.75. software systems because of the high cost of modifyingthe system.

196 Communications March 1982

of Volume 25
the ACM Number 3
 We describe some of the work that is needed in order cludes management procedures to control the process o f
to make programmers more effective and attempt to development and the deployment of these technical
characterize the changes in the nature of programming methods. The management and technical aspects of the
that will accompany these envisioned developments. We methodology have a synergistic relationship: the techni-
have arbitrarily divided our view into three sections: (1) cal methods provide the intermediate results needed for
the short term, covering the next five years; (2) the effective managerial control while the management pro-
medium term, from the mid-1980's through the end of cedures serve to allocate technical resources and to sup-
the century; (3) the long term, covering the early part of port the development organization.
the 21 st century.
Many of our ideas are, of necessity, speculative. It is Software Tools
not yet possible to provide quantitative data in support Another critical aspect of a methodology, however,
of these projections. Nevertheless, we have tried to pro- is an automated development support system (ADSS) in
ject some trends based on recent and emerging devel- which there is computer-based support for some (not
opments in hardware and software technology and have necessarily all) of the tasks carried out as part of the
pointed to supporting evidence where possible. methodology. The ADSS contains a number of auto-
In setting the time frame for some o f these advances, mated tools and utilities that can be used by the devel-
we have estimated the mean point at which we expect oper in the course of a project. Among the most common
the practices and tools to be in use. We recognize that examples of such tools are text editors and compilers; file
there may be a sizeable time span (5-15 years) from the copying and printing routines are among the most com-
time that the feasibility of an idea is demonstrated to the mon utilities.
time that an idea goes into practical application to the At present, the state of the art of software tools leaves
time that it is widely accepted and used. Another way to much to be desired. This is not to say that there are no
gauge the estimates is by the time at which the average good tools. Indeed, there are a number of sophisticated
programming organization will adopt the ideas, with the and effective tools [22, 27, 30] and there are several
understanding that the "leading edge" organizations will programming environments, notably Unix [21], INTER-
be several years ahead, and the laggards a decade or LISP [36], and Multics [11], that include a substantial
more behind. 2 number of such tools. Our point is that there are few
Our purpose, more than that of prognostication, is to settings in which the tools actually work effectively in
identify some goals for research in programming meth- harmony with one another and in support of a software
odology and software engineering, with the intent of development methodology.
encouraging additional work on the key areas that would There are two extremely serious problems with most
lead to improved development environments. of these tools. First, they fail to support a software
development methodology or to capture any data that
assists in control of the software development process. A
The Short Term qualitative improvement in tools to provide this critical
missing dimension and to augment the power of the tools
Efforts to improve programmer effectiveness over the is needed.
short term will involve development of software tools, Second, present tools primarily support coding activ-
increased use of high level languages, and environmental ities and fail to support the software development life
changes. These changes may each be expected to produce cycle in its entirety. There is a need for more tools to
incremental improvements in the productivity of pro- assist with software specification, design, and testing, as
grammers; more importantly, however, they will set the well as with management of software projects. For ex-
stage for more significant changes over the medium to ample, there are tools that assist with problem specifi-
long term. cation such as P S L / P S A [35], or detailed design such as
Many organizations are presently working to create a program design language, but they address only a
their own software development methodology, a sys- portion of the development process and must be incor-
tematic procedure that they can follow from the original porated into methodologies for software development.
concept of a system through its specification, design, These points are discussed at greater length in [16].
development, operation, and evolution [7, 12, 26, 28, 29, In addition to these primary problems, there are a
38, 40, 48]. Such a methodology includes technical number of secondary problems with present tools:
methods to assist in the critical tasks of problem solving,
documentation, hierarchical decomposition, design rep- (1) Lack of compatibility--tools are difficult to combine
resentation, coding, systematic testing, and software con- with one another, both at the direct interface level
figuration management. Such a methodology also in- and at the user level; some tools cannot even use the
same data or file formats.
(2) Lack of uniformity--the available set of tools differs
2Notable recent examples of this phenomenon are the use of
structured programming techniquesand the use of a modern program- among different machines, operating systems, and
ming language such as Pascal. languages, making it difficult for a programmer to
197 Communications March 1982
of Volume 25
the ACM Number 3
 move easily from one development environment to transition from one phase of the life cycle to another
another. (both forward and backward!) In this way, information
(3) Lack of tailorability--most tools are designed to be gathered at successive stages of the life cycle can be
used in predetermined ways and cannot easily be applied to subsequent stages and properly validated.
customized to support different patterns of use by Finally, the environment must support not only the
different developers. individual programmer but also the management of
software development. Two kinds of management are
Recently, there has been widespread recognition of essential: configuration management and management
these problems, with a resulting effort to develop better of software development personnel. Software configu-
software tools [17, 30]. One example of such an effort is ration management [5] involves keeping track of all of
the effort by the U.S. Department of Defense to specify the documentation associated with a project along with
needed tool capabilities to support the development of the emerging product, perhaps in multiple versions.
programs written in Ada [1]. Preliminary efforts are Information about individual productivity and the
underway to develop tools that overcome some of these amount of effort associated with various parts of a
deficiencies and to gather some evaluative data on the software project organized either by project phase or by
use of tools. module can also be collected. Such information is partic-
As these tools are developed, it will be necessary to ularly valuable in gaining a better understanding of the
integrate them into development environments [3, 17, 39], software development process itself, which can lead both
exemplified by the Ada Program Support Environment to better techniques for estimating the effort required for
framework, intended to provide the developer with a new projects and to identification and development of
standard, uniform set of tools. Such an environment can improved development environments.
represent both a qualitative and quantitative advance In the short term, these tools will be developed to
over today's state of the art. In order to meet this goal, operate on existing systems, using current terminals and
the tools that are created for this enviornment will have hardware. Over the next five years, however, develop-
to possess certain characteristics: ment systems will become increasingly sophisticated and
development environments will be created on personal
(1) Singularity ofpurpose--each tool should carry out
one well-defined function or a small number of development systems, specifically to support the task of
closely related tasks that perform a single function. system development [16].
(2) Ease of use--the user must not need elaborate knowl-
edge in order to be able to use a tool. High Level Languages
(3) Levels of use--the casual user of a tool should be There is now considerable experience in the use of
able to gain a substantial portion of the benefits of high level languages for a broad variety of programming
the tool with only a small subset of its available tasks including the development of systems software. A
facilities, while the sophisticated user of the same number of highly sophisticated systems including oper-
tool may be able to gain additional benefits through ating systems, e.g., Multics and Unix, and telephone
the complete set of features. switching systems, have been successfully written in high
(4) Consistency with other tools--each tool should have level languages. Indeed, some computers, e.g., Burroughs
a standard interface that enables it to be used in B6800, have no visible machine-level language at all.
conjunction with other tools, and should have a set Programs written in high level languages are less
of usage conventions that conforms to those of other error-prone than programs written in machine languages
tools in the environment (i.e., the Unix "pipe" mech- and programmers are more productive in high level
anism is a good example of thisconsistency). languages [14]. A generally accepted rule of thumb is
(5) Adaptability--tools should be adaptable to specific that the number of lines of code written by a programmer
user requirements and should support different pat- in a day is constant, regardless of the language used.
terns of use by different classes of users; furthermore, Since a statement in a high level language represents a
tools should contain a meaningful set of defaults that number of instructions at the machine language level, a
can be altered by the user in order to tailor it to programmer may normally complete the programming
individual preferences and needs. task more rapidly in a high level language.
(6) Local intelligence--tools should be designed to col- This situation holds for those languages that are in
lect information in a private database concerning widespread use today, e.g., Cobol, PL/I, and Fortran. A
profiles of usage of the tool; the data thereby cap- principal goal of much of the recent work in program-
tured could assist in the evolution of that tool and in ming language design, beginning with Pascal [46] and
the development of new tools. continuing through Ada [18] and other newer languages
[23, 25, 42], has been to provide features that will enhance
Taken as a whole, the collection of tools must provide both the quality of programs and the productivity of
support for the software life cycle, providing not only programmers still further.
technical support for a specific phase of the life cycle but A major shortcoming of the present high level lan-
also management assistance and a mechanism for the guage development environment is that very few of the

198 Communications March 1982

of Volume25
the ACM Number 3
support tools are integrated with the language itself. In A large portion of programmer overhead is attribut-
particular, the programmer trying to debug a high level able to the time associated with routine chores and
language program often must work with debugging tools clerical tasks. Advances in office automation including
that require use of the machine instructions generated word processing systems for documentation, automated
by the language compiler. There is a clear need for mailing systems, and the like, can substantially reduce
improved debugging tools tied to the source text of the the time needed for these activities. The software devel-
program. opment activity can be integrated with the capabilities
Indeed, the high level language development setting of the "electronic office," which offers the developer
provides an excellent example of the need for improved many features to organize and utilize time more effec-
tool integration. If a runtime error occurs in a program tively as well as to help facilitate better communication
during its development, the debugging tools should im- and information sharing among peers and management.
mediately be available to assist the programmer in iden-
tifying the source(s) of the error; it should then be Prototyping of Systems
possible to invoke the editor to change the program and One of the key problems in analysis and specification
rerun it, or to exercise the program more thoroughly with of systems is that the eventual users do not have a good
an automatically generated set of test data. idea of what they want the system to do. Without such
The improved productivity to be gained from high an idea, they are unable to communicate their needs
level languages suggests the need to work for still higher effectively. Furthermore, they have a difficult time in
level languages, particularly for use in application areas. reviewing a written specification to see whether or not it
While we do not expect currently used languages such as will satisfy their needs for functionality, ease of use, and
Fortran, Cobol, and BLISSto disappear, nor do we expect compatibility with their organization. Instead, they ap-
systems programmers to shift away from procedural prove the written specification and must then wait for a
programming languages, there is a significant role for substantial interval of time before they can use the actual
very high level languages that are nonprocedural or system. It is only at that time that they are able to gain
descriptive in character. experience with the system and to recognize its strengths
Excellent examples of such languages are the query and weaknesses. The release of such a system into an
languages for database management systems, e.g., SQL acceptance test or operational phase is thus typically met
[9] and Query by Example [50]. Such languages have with a flurry of requests for changes, many of which
been designed to provide the nonprogrammer with the require additional analysis and redesign. The result of
ability to formulate queries and thereby receive data this process is further delay in the availability of a usable
from a database. In the past, it was necessary to write ad system, along with added software expenses and poten-
hoc programs to generate the appropriate reports. Now tial loss of system structure due to the changes.
the end user can specify a request and formulate a query Instead, it would be far superior to provide develop-
in a nonprocedural language, thereby eliminating the ment tools that permit the rapid construction and mod-
need for a programmer. ification of system prototypes [44]. The developer could
then present the user with a prototype of the user-pro-
Environmental Issues gram interface, for example, and the user could experi-
Many programmers spend relatively little time ac- ment with the prototype to see if all of the desired
tually doing programming, i.e., writing, debugging, test- functions were available and if the format of the dialogue
ing, or documenting code. Much of their time is occupied was comfortable. For programs providing conversational
with mundane chores, meetings, or various kinds of access to databases, for example, an effective prototyping
breaks and interruptions. Additional time is taken in tool can be constructed from a dialogue processor and a
becoming familiar with new applications or new devel- database management system.
opment environments. Several important benefits could be derived from the
While it is unreasonable to expect a programmer to ability to create prototypes including:
spend all of his time performing programming tasks, it
(1) More effective user participation in the early project
is clear that there is much room for improvement in
stages;
programmer effectiveness. Some gain can be brought
(2) The user could have a temporary version of the
about by the improvement and standardization of tools
system (the prototype) to use while the production
previously discussed; additional gains can be achieved
version was being built; 3
through environmental changes.
(3) Development and maintenance costs would be re-
For example, the programmer's physical work envi-
duced because problem areas and errors could be
ronment seems to relate closely to productivity. Such
identified and corrected at a much earlier stage in
factors as noise level, smoke, terminal type and speed,
lighting, and access to library materials and documen-
tation can all affect the programmer, although different 3 In some situations, particularly where efficiency is not important,
where the expected lifetime and usage of the system is small, and
programmers will be affected to varying degrees by where development funds are limited, the prototype system alone
different factors. might suffice.

199 Communications March 1982

of Volume 25
the ACM Number 3
 the software life cycle, reducing the need to redo based on concepts of systematic programming and
pieces of the system; programming methodology.
(4) It would be possible to experiment with the user As these changes occur, the character of software
interface from a human factors perspective [8, 24, 34, itself will change as the cost of creating one-of-a-kind
41] so that the resulting system would be easy to systems becomes increasingly expensive.
learn and easy to use.
The Changing Nature of Software
Summary: The Short Term Experience has shown that development of a high-
These changes, which focus upon improved tools and quality software product of any significant size (>50
environments, are well within the boundaries of currently modules) requires, at a minimum, five person-years of
available technology and can be achieved within three effort over two years. It thus becomes obvious that very
to five years. Each of them can have significant beneficial few organizations can afford to purchase custom-built
effect upon programming, giving the programmer a software. The benefits of mass production are apparent,
greater degree of job satisfaction and making it easier as the development and evolutionary costs can be am-
for the programmer to carry out the software develop- ortized over a number of customers. Similarly, the de-
ment and evolution tasks. velopment of software tools to be used by a number of
However, none of these changes will have a signifi- different programmers in a number of different organi-
cant effect upon the nature of programming, and hence zations is seen to be beneficial since it can provide two
the expected improvements will only be incremental. kinds of leverage: mass production plus improved devel-
Indeed, the current trends could be expected to continue oper productivity.
as more programmers work on the software tools and At present, most organizations owning computers
development environments described here. It is only have sizeable staffs to develop and maintain custom
after these tools are developed and in place that some of software. However, the growing availability of personal
the more far-reaching changes will begin to take hold computers, ranging from hobby computers to personal
and to change the fundamental character of program- development systems, is rapidly changing that situation.
ming. Soon, the majority of computers will be in the hands of
people who are not (and do not wish to become) profes-
sional software developers. Such people will want to
purchase a computer system with a collection of available
The Medium Term
software that adequately performs a specific set of func-
tions.
More significant changes are foreseen from 1985 until
As a result, the bulk of software development will
the end of the century. These changes will be evolution-
shift to address that market whose characteristics differ
ary and can be traced from the present, as well as from
from those of the traditional software market. First of
assessment of future hardware technology. These
all, people who spend no more than a few thousand
changes involve a gradual shift toward greater automa-
dollars for a computer system are not going to be willing
tion of the development process and the ability to make
to spend more than that sum for the software. Hence,
use of a growing library of program pieces. Some of
the software produced must be inexpensive.
these changes will be evident in sophisticated organiza-
It is clear that the customer cannot expect to acquire
tions within the next few years but it will be a decade or
custom-built software. Instead, the customer will seek
more before these notions have a widespread impact.
out reliable, economical, easy-to-use software that meets
These expected changes fall into four major classifi-
specific needs. From the standpoint of the software
cations:
vendor, it is not practical to provide ongoing support for
(1) Development of certified software components--a these software packages; instead, the developer must
body of rigorously tested and thoroughly docu- provide a high quality package that meets identified
mented software modules will be created and avail- needs for a large user community and sell enough copies
able for easy incorporation in new systems; of the software to make up for the development cost, in
(2) Personal development systems--the programming en- much the same way that book publishers operate.
vironments developed over the next five years will In short, most software will come entirely without
be incorporated into stand-alone development ma- support. Software vendors who consistently produce
chines that can be interconnected to one another; poor software will simply lose out in the marketplace as
(3) Automated code generation from design languages and consumer guides and knowledgeable consumers distin-
program schemas--it will be possible to produce guish the good software from the bad in terms of usabil-
executable programs automatically for certain com- ity, reliability, documentation, and value received for
mon classes of systems from a description of the money spent.
system inputs and associated desired outputs; Software vendors may be expected to provide limited
(4) Improved programming l~guages--there will be warranties for their products in much the same way that
much greater use of modem programming languages vendors of other kinds of products, e.g., toasters, provide

200 Communications March 1982

of Volume 25
the ACM Number 3
warranties. Indeed, one can expect to see occasional basic software building blocks. Careful study will be
product recalls to correct faulty software. Vendors will needed to identify the appropriate components for var-
almost certainly not provide ongoing support for their ious application areas. Furthermore, candidate compo-
software, however. Rather, like textbook publishers, they nents will need to be studied to determine whether they
will provide new editions from time to time, and a are, in fact, made up of other candidate components.
customer who wants the latest version will have to dis- Gradually, standard functional components must be-
card the old version and purchase the new one, with at come the major building blocks for future software sys-
best a small trade-in allowance. tems, replacing those that have repeatedly been con-
All this is not to say that the market for custom-built structed from low-level primitives in the past [4].
software will disappear, any more than Savile Row is The programmer of the future will then work with
likely to disappear as a source of custom-made suits. these standard components, programming in the large
There will always be customers who, for various reasons, [13] with a decreased need for programming in the small.
are willing and able to spend the money for custom In order to encourage software developers to make use
development and ongoing support including mainte- of such components, it will be necessary to provide a
nance and enhancement. As with clothing, though, the great deal of information about the components so that
market for "off-the-rack" software will soon dominate they are accepted and used with confidence.
the industry. Accordingly, software components will have to be
In order to minimize the cost of this body of software, subjected to rigorous quality control and must be deliv-
it will be necessary to apply the techniques of mass ered with unambiguous specifications, comprehensible
production including standardized design techniques and documentation, and data describing its performance
control expenditures for optimization and testing. The characteristics. Of course, the components will also have
desire to reduce production costs involves use of many a warranty; for some classes of components, some kind
of the same techniques that are common in other kinds of formal verification may be appropriate. This compo-
of mass production endeavors including interchangea- nent description must be given without resorting to
bility of parts, specialization of personnel and tools, and implementation details. It is necessary to devise compact,
work environments to improve productivity. unambiguous, standard representations of the compo-
nents and their relevant properties, perhaps in a manner
Software Components similar to the technical data accompanying a product
A software system may be seen to consist of a number like a stereo receiver.
of components. Typically, the construction of software
systems requires that each component be built specifi-
Personal Development Systems
cally for each system. There is very little reuse of com-
As discussed previously, considerable effort will go
ponents from one system to another and few standards
toward the development of software tools in the short
for the development of these components. If we are to
tenn. In the medium term, these tools will be integrated
proceed toward the goal of engineering the creation of
into a hardware/software development environment that
software, it is necessary to make more effective use of
can make it possible for the individual software devel-
previously built software [43].
oper to live and work via a personal machine that
In order to make this possible, we must first identify
provides the maximum possible support for the devel-
a large number of frequently required functions in soft-
oper's various activities. In addition to the obvious sys-
ware systems and then develop a corresponding inven-
tem development work, the machine can serve as a
tory of program components that can easily be modified,
vehicle for a number of important tasks:
reconfigured, and reused. Such an inventory will be
roughly analogous to the inventory of prefabricated cir- - - T e x t processing, including the preparation of system
cuits available from semiconductor manufacturers, and documentation, technical papers and reports, and cor-
the task of the software implementer will more closely respondence, as well as editing or reviewing material
resemble that of the computer designer, who determines typed by others;
the gross system structure and the interconnections be- --Information storage and retrieval, including docu-
tween circuits but relies on the prefabricated components ments associated with various software development
for low-level operations. Over the past few years, we projects, telephone directories, mailing lists, and per-
have seen the development of increasingly larger and sonal data bases;
more complex hardware components, providing a greater --Communication, including the sending and receiving
range of components from which to select, with the of mail throughout both a local network and a larger
corresponding potential to restrict low-level alternatives network involving remote access and conferencing
severely. A similar trend in the development of software with one or more persons via these networks;
components is needed. --Self-management including a long-term diary, short-
Although some software components already exist, term (day or week) scheduling, and a "to-do" list, with
few have been subjected to rigorous testing and evalua- reminders that can be automatically triggered by a
tion to determine the extent to which they truly constitute system clock.

201 Communications March 1982

of Volume25
the ACM Number 3
 We may call such a development system a "profes- --Query languages, as mentioned above, that decompose
sional programmer based system" (PPBS). The typical the nonprocedural request and generate the appropri-
configuration for a PPBS will provide the programmer ate operations on the underlying database (which, in
with at least the computing power available in a present- turn, uses the access paths for the underlying file
day medium scale time-sharing system. The components system);
of this configuration will include: --Cobol program generation from the input structures,
output structures, and operation lists created through
- - A n intelligent terminal having approximately 1 Mbyte
use of the Jackson Design Methodology [19].
of primary memory and the computing power and
address space of today's 32-bit minicomputers; The class of application for which this type of pro-
--Local secondary storage (e.g., a Winchester disk) with gram generation can be performed will continue to in-
upwards of 40 Mbyte of storage capacity as well as crease so that many of the most common kinds of
some removable media (e.g., floppy disk); programs can be produced without having to resort to
--Graphics capability including multiple character fonts, the level of detail presently required for programming.
reverse video, variable intensity, split screen, color, Although there will always be boundaries upon ac-
and the ability to display a standard page of text ceptable response times and performance, the general
completely on the screen; issue of performance for some of these applications will
--Networking capability, to connect with other PPBS's be clearly secondary to the ability to express the problem
in a local network and to geographically dispersed and to obtain the solution without substantial program-
systems; ming effort. Functionality, generality, and correctness
--Audio input/output. will be the predominant considerations.
Within this framework, it should be possible to add Modern Programming Languages
additional primary and secondary storage as well as The 1970's have seen a vast amount of activity in
other kinds of peripheral devils, e.g., a print-quality programming language design based on the recognition
hardcopy device. This configuration not only provides that the features of a programming language have a
powerful local processing but opens up a broad range of strong effect upon the quality of the resulting software.
possibilities for user interaction, permitting the use of While it is possible to write a coherent and well-struc-
windows and menus for task selection and sequence tured program in a "bad" language, and possible to write
control as well as incorporating pictures and eventually an incomprehensible and unmaintainable program in a
voice input. Given the present rate of reduction in hard- "good" language, it seems clear that there are various
ware costs, it should be possible to produce a PPBS in languages and language features that encourage good
the price range of $10K-$20K by the late 1980's. programming practices and others that hinder the use of
The potential benefits of the PPBS are substantial such practices [47].
and can not only make the development organization Work on the design of a number of languages during
more productive but can also improve software quality. the last decade has identified a number of features that
Among the advantages that the PPBS can provide over seem to be valuable for writing high quality programs,
the time-sharing approach presently used are improved regardless of the intended application area. These fea-
reliability of hardware, improved hardware performance, tures include support for abstraction, particularly ab-
private mass storage, and support for nonkeyboard input. stract objects, support for modularization including sep-
arate compilation of modules, support for linear flow of
Automation of Programming Tasks control through powerful language control structures,
As we gain experience in the design and development the use of data types and type checking, and, finally,
of software systems and as we identify a body of software exception handling to make programs robust against
components, certain common program structures and various kinds of exceptional runtime conditions, includ-
schemas emerge. For example, a command processing ing, but not limited to, user input errors.
program can immediately be decomposed into an input Pascal possesses several of these properties and serves
part, a decoding part, and a dispatching part, with each as the model for the design of a number of new program-
separate command handled by a separate program mod- ming languages, of which Ada seems likely to become
ule. This decomposition is so intuitive that it leads to a the most commonly used. There is preliminary evidence
very straightforward kind of programming, where one that the programming discipline inherent in the use of
can simply use a standard program schema and insert Pascal and its descendants has a beneficial effect on
the appropriate commands and actions. (This particular software quality and programmer productivity [14]. The
schema is termed the "transaction model" in Structured widespread use of these new languages and language
Design [49].) support systems should have a measurable effect on the
There are already a number of systems that carry out programming task.
this kind of task: While it will remain necessary to use presently avail-
--Parser generators used to construct compilers and able languages for the maintenance and enhancement of
other language processing programs [20]; the large body of software already in existence, newer

202 Communications March 1982

of Volume 25
the ACM Number 3
languages based on these ideas of programming meth- revolutionary breakthrough will occur and invalidate all
odology will increasingly be used for new applications. of the predictions or sharply compress the time scale.
The use of natural language as a programming lan- Such has certainly been the case with computer hard-
guage has long intrigued computer scientists and there ware. Our projections are based primarily on the fore-
have been several projects that have made significant seeable advances over the short and medium term and
strides toward natural language comprehension by com- may therefore be regarded as relatively conservative.
puter [32, 37, 45]. We believe that there will be an Furthermore, it is more difficult to be specific about the
increasing number of systems that accept input in a form likely advances. Accordingly, our notion of the long term
approximating natural language. Such systems can be concentrates on the first few decades of the 21 st century.
particularly useful for the computer-naive user. The The short and medium term advances in program-
potential utility of natural language for database retrieval ming focused heavily on the development of software
has been demonstrated [10]. tools, the creation of development environments, and the
Yet natural language has some important shortcom- means to make use of experience in software develop-
ings when considered as a programming language. First, ment, while retaining a large measure of the present
the volume of input may be much larger than that orientation with procedural programming languages. It
required for either procedural or nonprocedural query seems likely that the longer term advances will change
languages. English is relatively compact in this respect the fundamental nature of programming.
but many other languages require more text to make This fundamental change will occur in several ways.
comparable statements. Second, natural language, par- First, much of the short term effort will be placed on
ticularly English, is inherently ambiguous. In order to developing interfaces that are appropriate for end users,
overcome this problem, systems must either incorporate making it feasible for such users to interact directly with
a sophisticated interactive procedure to resolve ambigu- the computer for many of their routine needs. Second,
ities or must restrict the input to an artificial subset of programmers will become able to express the desired
natural language or both. function of a program in terms of its expected behavior
Thus, we believe that people in computer science will and output(s) without having to specify the precise algor-
continue to write programs in an artificial language for ithms involved in performing the processing. Third,
quite some time and that natural language systems are many programmers will then move away from concern
more likely to be used by nonprogrammers as end users with the "how" of programming to concentrate more
of an application program. heavily on the "what"; applications programming will
then become equivalent to today's task of requirements
Summary: The Medium Term analysis and specification. In short, both the nature of
The medium term advances in programming are programming and the nature of programmers will
based largely on notions presently available as prototypes change.
in research and development settings. The advances in
software componentry and in automation of some kinds User Level Programming
of programming are largely empirical--experience in Today's query languages for database management
developing software systems leads to the identification systems are the forerunners of a much more sophisticated
of commonly used software structures and program mod- class of user level tools that will permit a user to request
ules. These can be made available as separate verified certain kinds o f operations from the computer without
components or can serve as models for programs that any substantial programming knowledge or effort. Tools
can generate a number of programs of a given class. such as report program generators and database retrieval
The PPBS pulls together the advances in software systems will be equipped with interfaces that facilitate
tools with the need for improved development environ- their use by nonprogrammers. Such interfaces, rather
ments and the capabilities of the electronic office. Each than requiring typing, as is the case with today's systems,
programmer can have a PPBS that may be customized will permit the user to interact in a variety of different
to specific personal needs and desires. modes including (spoken) natural languages and graph-
These medium term advances in programming set ics, as well as typing which will remain a viable alter-
the stage for more far-reaching advances in the next native in many situations.
century, as we develop additional techniques for describ- This form of user programming will have several
ing programs in a nonprocedural way and become able major benefits:
to apply the automatic programming notions to broader
classes of programs. - - T h e r e will be less need for expensive applications
programmers to write the programs to carry out these
tasks since users will be able to write simple programs;
The Long Term
--Application programmers can be concerned instead
There is considerable risk in trying to carry out with more general facilities, i.e., providing the tools
technology assessment in a field that is changing so that permit broader kinds of user level programming;
rapidly. There is a strong possibility that some kind o f - - U s e r s can request the data and reports they want as

203 Communications March 1982

of Volume 25
the ACM Number 3
 needed and as their requirements evolve, thereby elim- Thus, if it is possible to state a set of decision rules
inating a costly form o f maintenance. for a given problem, it will become a straightforward
task to implement those rules in a running program.
This is not to say that the profession of programming
Eventually, such rule-based systems will be able to ac-
will disappear--there will still be a need for systems and
commodate large knowledge bases, maintain integrity
applications programmers. 4 It is just that the increased
constraints on their databases, and verify consistency
growth in the use of computers will be accompanied by
among their rules. This feature will be particularly im-
a growth in tools that permit the users to carry out
portant when the knowledge base is modified.
common tasks directly, thereby minimizing the growth
It can be seen that the programmer's problem in such
in the number of programmers who must be familiar
a setting shifts away from the traditional concern with
with programming languages and internal software sys-
data representation and program structure and towards
tem details.
understanding of the problem itself, a task that is now
It should be noted that the software systems to sup-
carried out by analysts who communicate their under-
port user level programming will be extremely sophisti-
standing to programmers through some kind of specifi-
cated by today's standards and that the problems of
cation, which is then translated into a design and imple-
specification, design, and implementation of such sys-
mentation. In such a setting, optimization can be per-
tems will require highly skilled professional program-
formed by transforming the automatic solution or by
mers.
guiding the choices made by the automatic system [2].
The activities o f design and implementation require
Automatic Programming
additional people and additional time. Furthermore, the
The term "automatic programming" has been used
transition between the various phases with their inher-
for many years to refer to the process by which an
ently different representations is extremely error-prone.
executable program may be produced from nonproce-
Errors in the specification may not be found until the
dural specifications of the task to be performed. Some
program is tested and additional errors may be intro-
limited forms of automatic programming are already
duced during design and implementation. Hence, the
available and more will become available in the medium
ability to "implement the specification," whether it be in
term. Over the longer term, it will be possible for pro-
the form of rules or a formal specification language,
grammers to create running programs by providing a
provides substantial leverage in controlling software
specification o f program functions and outputs, without
costs. Furthermore, as these languages become easier to
having to proceed with a detailed program design or
use and increasingly expressive, it becomes easier to once
with the production of code.
again Customize systems for minor differences in user
Two major kinds of specification seem likely to
needs, a capability which is now becoming prohibitively
emerge. The first is derived from current work in the
expensive.
area o f formal specification languages, in which one is
able to describe functions and axioms upon sets of
The Programmer as Analyst
abstract objects, transforming one set of operations and
There is, at present, a difference between the systems
objects into another through successive refinements [15,
programmer and the applications programmer. This dis-
31]. These specification languages will be able to use
tinction is likely to grow stronger in the future as appli-
software components that automatically create represen-
cation programmers need to become more aware o f the
tations for the abstract objects as well as providing a set
requirements o f specific users and specific application
of operations. The specification language can be used to
areas and less aware of the low level machine details.
generate a program, perhaps in an applicative language,
We are presently on the verge of a vast explosion of
e.g., LISP, that will carry out the desired function.
computerized applications as the availability o f inexpen-
The second approach to specification applies current
sive hardware makes, the computer an indispensable
research in artificial intelligence. Many decision proc-
appliance in people's homes and an essential part of
esses can be expressed by a set of rules, e.g., diagnosis o f
almost every organization. The major roadblock to this
certain diseases. Work with such systems as M Y C I N [33]
path is the low usability o f present software. As software
has shown that it is possible to create a program skeleton
tools become more powerful, more programmers will be
that can accept a set of rules as a knowledge base and
available to work on applications tasks.
then produce a set o f actions that follows that set of
As we have seen, the need will not be for program-
rules. Such a program skeleton has been used to generate
ming skills in the traditional sense but for the ability to
a program for an unrelated application in a very short
communicate with users and to understand the needs o f
period of time.
these individuals and their organizations. Thus we may
expect future programmers to receive training not only
in a computer science-like discipline (essential for sys-
4To some extent, the distinction between systems programmers tems programmers), but also in an applications area.
and applications programmers is artificial. For our purposes, though,
we may characterizesystems programmersas those persons who must Such educational programs already exist in areas such
be aware of internal details of machine organization. as medical computing and management information sys-

204 Communications March 1982

of Volume 25
the ACM Number 3
tems where a large portion of the student's education is well-defined classes of problems. These changes then set
aimed at familiarization with the application area--its the stage for more substantial changes over the longer
structure, its information needs, and the roles of various term, turning much of today's programming task into a
personnel--rather than with the computing aspects of specification task and providing the users of computer
the applications. systems with a powerful collection of tools that permit
This need is reflected in the directions of research in them to carry out their applications without having to
software engineering. Much of the early work was in the rely upon programmers. These changes, in turn, leave
area of programming methodology. Much of the recent programmers free to provide increasingly powerful tools
work has focused on requirements analysis and specifi- and to work with users to identify their needs and
cation techniques including such activities as modeling formulate them for the computer.
organizational structures, functions, and information
flows. There is clearly a need for more powerful tools in Acknowledgments. We gratefully acknowledge the
this area to support the development of sophisticated constructive comments of many of our colleagues at the
applications. University of California and Digital Equipment Corpo-
ration on an earlier draft of this paper. We also appre-
Summary: The Long Term ciate D.D. McCracken's observation concerning the large
Clearly, the topics mentioned above represent only a variation in the adoption of new methods. Computing
small portion of the advances that are likely to occur in support for text preparation was provided by National
the software area over the next fifty years. Other topics Institutes of Health Grant RR-1081 to the UCSF Com-
that are important include such things as the relationship puter Graphics Laboratory, Principal Investigator:
between software environments and their underlying R. Langridge.
hardware, with its implications for system portability
and the need for system maintenance. Received 1/81; revised 9/81; accepted 10/81
Nonetheless, it can be seen that the nature of pro- References
gramming and programmers is certain to change, and 1. Advanced Research Projects Agency. Requirements for Ada
that an increasing share of what we now term program- programming support environments--'STONEMAN'. U.S.
Department of Defense, Arlington, VA, 1980.
ming will be carried out by user-operators, who will have 2. Balzer, R. Transformational implementation: An example. 1EEE
tools at their disposal that permit them to interact natu- Transactions on Software Engineering, SE-7, 1 (Jan. 1981), 3-14.
rally with a computer system and specify their requests. 3. Barstow, D., Shrobe, H., and Sandewall, E. (Eds.). Interactive
Development Environments. McGraw-Hill, New York, 1982.
It is only when such tools are provided that the exponen- 4. Belady, L.A. Evolved software for the '80's. Computer, 12, 2 (Feb.
tial growth in the number of programmers and the cost 1979), 79-83.
of software can be slowed and that attention may be 5. Bersoff, E.H., Henderson, V.D., and Siegel, S.G. Software
configuration management: A tutorial. Computer, 12, 1 (Jan. 1979),
devoted to making the greatest possible beneficial use of 6-14.
the computer. 6. Boehm, B.W. Software and its impact: A quantitative assessment.
Datamation, 19, 5 (May 1973), 48-59.
7. Boyd, D.L. and Pizzarello, A. Introduction to the WELLMADE
design methodology. IEEE Transactions on Software Engineering,
Conclusions SE-4, 4 (July, 1978), 276-282.
8. Card, S.K., Moran, T.P., and NeweU, A. The keystroke-level
model for user performance time with interactive systems. Comm.
Software design and development is the weakest link ACM, 23, 7 (July, 1980), 396--410.
in the system development process. It has become ex- 9. Chamberlin, D.D., et al. SEQUEL2: A unified approach to data
traordinarily and prohibitively expensive and remains definition, manipulation, and control. IBM J. Res. Develop. 20, 6
(Nov. 1976), 560-575.
unpredictable in terms of economically and dependably 10. Codd, E.F. How about recently? (English dialog with relational
producing programs that run reliably, correctly, and data bases using Rendezvous Version 1). In Databases: Improving
efficiently. Usability and Responsiveness. B. Shneiderman (Ed.) Academic Press,
New York, 1978, pp. 3-28.
We have now reached a point where experience in II. Corbato F.J., and Clingen, C.T. A managerial view of the
software development combined with advances in hard- Multics system development. In Research Directions in Software
ware technology and research into programming meth- Technology. P. Wegner (Ed.) The MIT Press, Cambridge, 1979, pp.
139-158.
odology and software engineering can all be brought to 12. Davis C.G., and Vick, C.R. The software development system
bear upon the problem. As a result, we have the oppor- IEEE Transactions on Software Engineering, SE-3, 1 (Jan. 1977) 69-
tunity to drastically alter the nature of programming in 84.
13. DeRemer F., and Kron, H. Programming-in-the-large versus
the foreseeable future. programming-in-the-small. 1EEE Transactions on Software
Over the short term, the benefits are incremental, Engineering, SE-2, 2 (June, 1976), 80--86.
based largely on the development of improved software 14. Gannon, J.D. and Homing, J.J. Language design for
programming reliability. IEEE Transactions on Software Engineering,
tools and their integration into programming environ- SE-1, 2 (June 1975), 179-191.
ments. Over the medium term, the benefits and changes 15. Goguen, J. and Tardo, J.J. An introduction of OBJ: A language
are more substantial, involving the construction of an for writing and testing formal algebraic program specifications. Proc.
Specifications of Reliable Software. IEEE Computer Society, 1979,
inventory of reusable and verifiable software compo- 170-189.
nents and the ability to generate programs for certain 16. Gutz, S., Wasserman, A.I., and Spier, M.J. Personal development

205 Communications March 1982

of Volume 25
the ACM Number 3
systems for the professional programmer. Computer, 14, 4 (April, 34. Smith, H.T., and Green, T.R. (Eds.). Human Interaction with
1981), 45-52. Computers. Academic Press, London, 1980.
17. Hunke, H. (Ed.). Software Engineering Environments. North 35. Teichroew, D., and Hershey, E.A., III, PSL/PSA: A computer-
Holland, Amsterdam, 1981. aided technique for structured documentation and analysis of
18. Ichbiah, J.D. (Ed.) Reference Manual for the Ada Programming information processing systems. IEEE Transactions on Software
Language, U.S. Department of Defense, Advanced Research Projects Engineering, SE-3, l (Jan. 1977), 41-48.
Agency, 1980. 36. Teitelman, W., and Masinter, L. The INTERLISP programming
19. Jackson, M.A. Principles of Program Design. Academic Press, environment. Computer, 14, 4 (April, 1981), 25-33.
London, 1975. 37. Walker, D. (Ed.). Understanding Spoken Language. Elsevier
20. Johnson, S.C., and Lesk, M.E. Language development tools. The North-Holland, New York, 1978.
Bell System Tech. J., 57, 6 (July-August 1978), Part 2, 2155-2175. 38. Wasserman, A.I. Information system design methodology, J. Am.
21. Kernighan, B.W., and Mashey, J.R. The Unix programming Soc. lnfo. Sci., 31, l (Jan. 1980), 5-24.
environment. Computer, 14, 4 (April 1981), 12-24. 39. Wasserman, A.I. (Ed.). Tutorial: Software Development
22. Kernighan, B.W., and Plauger, P.J. Software Tools. Addison- Environments. IEEE Computer Society, Los Alamitos, 1981.
Wesley, Reading, MA, 1976. 40. Wasserman, A.I. USE: A methodology for the design and
23. Lampson, B.W. et al., Report on the programming language development of interactive information systems. In Formal Models
Euclid. ACM S1GPLAN Notices, 12, 2 (Feb. 1977), 1-79. and Practical Tools for Information System Design. H.-J. Schneider,
24. Ledgard, H., Singer, A., and Whiteside, J. Directions in Human (Ed.). North Holland, Amsterdam, 1979, pp. 31-50.
Factors for Interactive Systems. Springer Verlag, Berlin,1981. (Lecture 41. Wasserman, A.I. User software engineering and the design of
Notes in Computer Science, vol. 103). interactive systems. Proc. 5th Int. Conf. on Software Engineering, San
25. Liskov, B. et al. CLU Reference Manual. Springer Verlag, Berlin, Diego, CA, pp. 387-393.
1981. (Lecture Notes in Computer Science, Vol. 114). 42. Wasserman, A.I. et al., Revised report on the programming
26. Lundeberg, M., Goldkuhl, G., and Nilsson, A. Information language PLAIN. ACM SIGPLAN Notices, 16, 5 (May, 1981), 50-80.
Systems Development. A Systematic Approach. Prentice-Hall, 43. Wasserman, A.I., and Belady, L.A. Software engineering: The
Englewood Cliffs, N J, 1981. turning point. Computer, 11, 9 (Sept. 1978), 30-41.
27. Miller, E.F., Jr. (Ed.) Tutorial: Automated Tools for Software 44. Wasserman, A.I., and Shewmake, D.T. Automating the
Engineering. IEEE Computer Society, Los Alamitos, 1979. development and evolution of user dialogue in an interactive
28. Neumann, P.G. Experience with a formal methodology for information system. In Evolutionary Information Systems.
software development. Proc. Int. Seminar on Software Engineering J. Hawgood and L. Methlie, (Eds.). North Holland, Amsterdam, 1981
Applications, Capri, 1980. (in press).
29. O'Neill, D. The management of software engineering--Part II: 45. Winograd, T. Understanding Natural Language. Academic Press,
Software engineering program. IBM Syst. J. 19, 4 (1980), 421-431. New York, 1972.
30. Riddle, W.E., and Fairley, R.E. (Eds.). Software Development 46. Wirth, N. The programming language Pascal. Acta Informatica,
Tools. Springer Verlag, Heidelberg, 1980. 1, l (1971), 35-63.
31. Robinson, L. The HDM Handbook, Volume 1: The Foundations 47. Wulf, W.A. Trends in the design and implementation of
of HDM. Project Report 4828, Computer Science Group, SRI programming languages. Computer, 13, 1 (Jan. 1980), 14-22.
International. 1979. 48. Yourdon, E. Software Development Methodology. Yourdon, Inc.,
32. Schank, R.C., and Rieger, C.J. Inference and the computer New York, 1982.
understanding of natural language. Artif. lntell. 5 (1974), 373-412. 49. Yourdon, E., and Constantine, L.L. Structured Design. Prentice-
33. Shortliffe, E.H. Computer-Based Medical Consultations: MYCIN. Hall, Englewood Cliffs, N.J., 1979.
American Elsevier, New York, 1976. 50. Zloof, M.M. Query by example. Proc. AFIPS 1975 NCC, 44,
New York, pp. 431-438.

206 Communications March 1982

of Volume 25
the ACM Number 3