Software Aging

Invited Plenary Talk

David Lorge Parnas

Communications Research Laboratory

Department of Electrical and Computer Engineering
McMaster University, Hamilton, Ontario, Canada L8S 4K1

ABSTRACT inevitable, but like human aging, there are things that
Programs, like people, get old. We can ‘t prevent we can do to slow down the process and, sometimes,
aging, but we can understand its causes, take steps to even reverse its effects.
limits its effects, temporarily reverse some of the Software aging is not a new phenomenon, but it is
damage it has caused, and prepare for the day when gaining in significance because of the growing eco-
the software is no longer viable. A sign that the nomic importance of software and the fact that in-
Software Engineering profession has matured will be creasingly, software is a major part of the “capital” of
that we lose our preoccupation with the jirst release many high-tech firms. Man y old software products
and focus on the long term health of our products. have become essential cogs in the machinery of our
Researchers and practitioners must change their society. The aging of these products is impeding the
perception of the problems of software development. further development of the systems that include
Only then will Sojlware Engineering deserve to be them.
called Engineering. The authors and owners of new software products
often look at aging software with disdain. They be-
lieve that, if the product had been designed using to-
day’s techniques, it wouldn’t be causing problems.
1 What nonsense!
Such remarks remind me of a young jogger scoffing
I can easily imagine the reaction of some computer
at an 86 year old man (who, unknown to the jogger,
scientists to the title of this paper.
was a champion swimmer into his 50’s) and saying
“Software is a mathematical product;
that he should have had more exercise in his youth.
mathematics doesn’t decay with time. If a theorem Just as we will all (if we are lucky) get old, software
was correct 200 years ago, it will be correct aging can, and will occur in all successful products,
tomorrow. If a program is correct today, it will be We must recognise that it will happen to our products
correct 100 years from now. If it is wrong 100 years and prepare for it. When old age arrives, we must be
from now, it must have been wrong when it was prepared to deal with it.
written. It makes no sense to talk about software The purpose of this paper is to explain how an ab-
aging.” stract, mathematical product can age and then to re-
view some of the approaches to dealing with it.
Like many such statements, the imagined quote is
true but not really relevant. Software products do ex- 2 The causes of software aging
hibit a phenomenon that closely resembles human ag- There are two, quite distinct, types of software ag-
ing. Old software has begun to cripple its once-proud ing. The first is caused by the failure of the product’s
owners; many products are now viewed as a burden- owners to modify it to meet changing needs; the sec-
some legacy from the past. A steadily increasing ond is the result of the changes that are made. This
amount of effort is going into the support of these “one-two punch’ can lead to rapid decline in the val-
older products. Like human aging, software aging is ue of a software product.

279
0270-5257/9 4$3.0001994 IEEE
2.1 Lack of movement becomes very expensive to update. Changes take

Over the last three decade, our expectations about longer and are more likely to introduce new “bugs”.

software products has changed greatly. I can recall Change induced aging is often exacerbated by the

the days when a programmer would “patch” a pro- fact that the maintainers feel that they do not have

gram stored on paper tape by using glue and paper. time to update the documentation. The documenta-

We were all willing to submit large decks of cards tion becomes increasingly inaccurate thereby making

and to wait hours or days for the job to compile and future changes even more difficult.

run. When interactive programming first came in, we 3 Kidney failure

were willing to use cryptic command languages. To- A problem that is often confused with, but is dis-
day, everyone takes on-line access, “instant” re- tinct from, software aging, is the system slow down
sponse, and menu-driven interfaces for granted. We caused by failure to release allocated memory. Files
expect communications capabilities, mass on-line may grow and require pruning. Sometimes a memory
storage, etc. The first software product that I built (in allocation routine may not release all the space that
1960) would do its job perfectly today (if I could find has been allocated. Slowly, swap and file space are
a Bendix computer), but nobody would use it. That diminished and performance degrades. This problem
software has aged even though nobody has touched it. is often a congenital design failure and can strike at
Although users in the early 60’s were enthusiastic any age; but it may also be the result of ignorant sur-
about the product, today’s users expect more. My old gery or exacerbated by changing usage patterns.
software could, at best, be the kernel of a more con- Nonetheless, it is more easily cured than the “aging”
venient system on today’s market. Unless software is that is the subject of this paper. A dialysis type proc-
frequently updated, it’s user’s will become dissatis- ess may intervene and clean up the file system and
fied and they will change to a new product as soon as memory, improved routines may cause the cleanup to
the benefits outweigh the costs of retraining and con- occur rapidly and the software may be considered
verting. They will refer to that software as old and completely “cured”.
outdated. 4 The costs of software aging
2.2 Ignorant surgery The symptoms of software aging mirror those of
Although it is essential to upgrade software to pre- human aging: (1) owners of aging software find it in-
vent aging, changing software can cause a different creasingly hard to keep up with the market and lose
form of aging. The designer of a piece of software customers to newer products, (2) aging software of-
usually had a simple concept in mind when writing ten degrades in its space/time performance as a result
the program. If the program is large, understanding of a gradually deteriorating structure, (3) aging soft-
that concept allows one to find those sections of the ware often becomes “buggy” because of errors intro-
program when an update or cor-
that must be altered duced when changes are made. Each of these results
rection is needed. Understanding that concept also in real costs to the owner,
implies understanding the interfaces used within the 4.1 Inability to keep up
system and between the system and its environment.
As software ages, it grows bigger. This “weight
Changes are made by people who do not under- gain” is a result of the fact that the easiest way to add
stand the original design concept almost always cause a feature, is to add new code. Modifying existing
the structure of the program to degrade. Under those code to handle the new situations is often difficult be-
circumstances, changes will be inconsistent with the cause that code is neither well-understood nor well-
original concept; in fact, they will invalidate the orig- documented. As the size of a program increases,
inal concept. Sometimes the damage is small, but of- sometimes by one or two orders of magnitude over a
ten it is quite severe. After those changes, one must
period of several years, changes become more diffi-
know both the original design rules, and the newly in-
cult in a variety of ways. First, there is more code to
troduced exceptions to the rules, to understand the
change; a change that might have been made in one
product. After many such changes, the original de-
or two parts of the original program, now requires al-
signers no longer understand the product. Those who tering man y sections of the code. Second, it is more
made the changes, never did. In other words, nobody
difficult to find the routines that must be changed. As
understands the modified product. Software that has
a result, the owners are unable to add new features
been repeatedly modified (maintained) in this way
quickly enough. Customers may switch to a younger

2s0
product to get those features. The company experi- Too many papers at software engineering confer-
ences a notable drop in revenue; when they bring out ences focus on the problems of getting to the first re-
a new version, it is of interest to a dwindling custom- lease. Too many papers focus on the management
er base. If they do attempt to keep up with the market, issues, (e.g. configuration management and control).
by increasing their work force, the increased costs of Dealing with software aging requires more than “pa-
the changes, and the delays, lead to further loss of tient management”; it requires solid engineering. It is
customers. the purpose of the remainder of this paper to consider
4.2 Reduced performance \ what actions we might take to reduce the costs asso-
As the size of the program grows, it places more ciated with Software Aging.
demands on the computer memory, and there are 6 Preventive medicine
more delays as code must be swapped in from mass Since software aging is such a serious problem, the
storage. The program responds more slowly; custom- first question we must ask is what we can do to delay
ers must upgrade their computers to get acceptable the decay and \imit its effects.
response. Performance also decreases because of 6.1 Design for success
poor design. The software is no longer well under-
The first step in controlling software aging is ap-
stood and changes may adversely affect performance.
plying the old slogan, “design for change”. Since the
A younger product, whose original design reflected
early 70’s we have known how to design software for
the need for recently introduced features will run fast-
change. The principle to be applied is known by vari-
er or use less memory.
ous names, e.g. “information hiding”, “abstraction”,
4.3 Decreasing reliability “separation of concerns”, “data hiding”, or most re-
As the software is maintained, errors are intro- cently, “object orientation”. To apply this principle
duced. Even in the early years of the industry, observ- one begins by trying to characterise the changes that
ers were able to document situations in which each are likely to occur over the “lifetime” of the product.
error corrected introduced (on average) more than Since, we cannot predict the actual changes, the pre-
one error. Each time an attempt was made to decrease dictions will be about classes of changes, e.g. revised
the failure rate of the systems, it got worse. Often the expression representation, replacing of the terminal
only choice was to abandon the product or at least to with a new type, changes in the user-interface,
stop repairing bugs. I have been told of older software change to a new windowing system, etc. Since it is
products in which the list of known, but not yet re- impossible to make everything equally easy to
paired, bugs, exceeded 2000 entries. change, it is important to estimate the probabilities of
5 Reducing the costs of software aging each type of change. Then, one organises the soft-
Inexperienced programmers can often be recog- ware so that the items that are most likely to change
nised by the elation that they show the first time that
are “confined” to a small amount of code, so that if
they get correct results from a program. “I’ m done; it
those things do change, only a small amount of code
works !“ is the shout of a new programmer who has
would be affected. In spite of the simplicity of this
1. The experi- principle, and in spite of its broad acceptance, I do
just had a successful first demonstration
enced programmer realises that this is just the begin- not see much software that is well designed from this
ning. They know that any serious product requires point of view. It is worthwhile to examine some of
the reasons for the industry’s failure to apply this
extensive testing, review and revision after the first
successful run. The work that is invested by responsi- principle.
ble, professional, organisations after the first success- ● Man textbooks on software mention this tech-
ful run and before the first release is usually much nique 1, but they cover it in a superficial way. They
say that one should hide, or abstract from “imple-
greater than that required to get the first successful
mentation details”, but they do not discuss, or illus-
run. However, even experienced programmers focus
trate, the process of estimating the probability of
on that first release. Our experience with software ag- change for various classes of changes. The princi-
ing tells us that we should be looking far beyond the ple is simple; applying it properly requires a lot of
first release to the time when the product is old.

1 Students get this “rush” with the first error-free compila- 2 It is so well-accepted, that textbooks often fail to point
tion. out the places where the idea first appeared.

281
 thought about the application and the environment. do it. I suspect that some programmers think that
The textbooks do not make that clear. their program will be so good that it won’t have to be
● Many programmers are impatient with such consid- changed. This is foolish. The only programs that
erations; they are so eager to get the first version don’t get changed are those that are so bad that no-
working, or to meet some imminent deadline, that body wants to use them. Designing for change is de-
they do not take the time to design for change. Man- signing for success.
agement is so concerned with the next deadline (and
6.2 Keeping records - documentation
so eager to get to a higher position) that future
maintenance costs don’t have top priority. Even when the code is designed so that changes
● Designs that result from a careful application of in-
can be carried out efficiently, the design principles
formation hiding are quite different from the “natu- and design decisions are often not recorded in a form
ral” designs that are the result of most that is useful to future maintainers. Documentation is
programmer’s intuitive work. The programmer’s in- the aspect of software engineering most neglected by
tuition is to think about steps in the data processing, both academic researchers and practitioners. It is
not likely changes. Even when told to associate common to hear a programmer saying that the code is
each module with a “secret”, something that is like- it’s own documentation; even highly respected lan-
ly to change that should be encapsulated, they use guage researchers take this position, arguing that if
“secrets” of the form, “how to ....“, and make each you use their latest language, the structure will be ex-
module perform some step in the processing, often plicit and obvious.
violating the information hiding principle in the
When documentation is written, it is usually poorly
process.
organised, incomplete and imprecise. Often the cov-
Designers tend to mimic other designs that they
erage is random; a programmer or manager decides
have seen. They don’t see many good applications
of information hiding. One example of information that a particular idea is clever and writes a memo
hiding design is [9] about it while other topics, equally important, are ig-
Programmers tend to confuse design principles nored. In other situations, where documentation is a
with languages. For example, they believe that one contractual requirement, a technical writer, who does
cannot apply “object-oriented” ideas without an not understand the system, is hired to write the docu-
“object oriented” language. Even worse, they think mentation. The resulting documentation is ignored
that one has applied the techniques, if one has used by the maintenance programmers because it is not ac-
such a language. curate. Some projects keep two sets of books; there is
Many people who are doing software development, the official documentation, written as required for the
do not have an education appropriate to the job. contract, and the real documentation, written infor-
Topics that are “old hat” to those who attend this mally when specific issues arise.
conference are unknown, or vague jargon, to many Documentation that seems clear and adequate to its
who are writing software. Each industry has its own
authors is often about as clear as mud to the program-
software conferences and many programmers in
mer who must maintain the code 6 months or 6 years
each industry work as if their problems were
later. Even when the information is present, the main-
unique.
tenance programmer doesn’t know where to look for
Software Engineering researchers continue to
it. It is almost as common to find that the same topic
preach to converted, to write papers for each other,
and to ignore what is happening where the majority is covered twice, but that the statements in the docu-
software is written, They assume that “design for mentation are inconsistent with each other and the
change” is an old problem, not one that requires fur- code.
ther work. They are wrong ! Documentation is not an “attractive” research top-
Thus, although the principle of information hiding ic. Last year, I suggested to the leader of an Esprit
was first enunciated in the early 70’s, (and illustrated project who was looking for a topic for a conference,
even earlier), it is rare to find a software product that that he focus on documentation. His answer was that
was properly designed from this point of view. The it would not be interesting. I objected, saying that
code is often clever, efficient, and correct; it performs there were many interesting aspects to this topic. His
rather amazing functions, but rarely is it designed to response was that the problem was not that the dis-
be easily changed. The problem is not that nobody cussion wouldn’t be interesting, the topic wouldn’t
knows how to do it, but that most programmers don’t sound interesting and would not attract an audience.

282
 For the past five or six years my own research, and man y reasons for this:
that of many of my students and close colleagues, has ● Many programmers have no professional training
focused on the problems of documentation. We have in software at all. Some are engineers from other
shown how, mathematical methods can be used to fields, some are “fallen scientists” who learned pro-
provide clear, concise, and systematic documentation gramming incidentally while getting their educa-
of program design [3,4]. We have invented and illus- tion. Some were mathematicians, and some came
from non-technical backgrounds. In many of those
trated new mathematical notation that is much more
areas, the concept of preparing and holding a de-
suited to use in documentation, but no less formal
sign review is nonexistent.
[5,6,7]. The reaction of academics and practitioners
● Even among those that have Computer Science de-
to this work has been insight-provoking. Both sides
grees have had an education that neglected such
fail to recognise documentation as the subject of our
professional concerns as the need for design docu-
work. Academics keep pointing out that we are ne-
mentation and reviews. The emphasis is on the
glecting “proof obligations”; industrial reviewers mathematics and science; professional discipline is
classify our work as “verification” which they (often not a topic for a “liberal” education.
correctly) consider too difficult and theoretical, Nei- ● Most practitioners (and many researchers) do not
ther group can see documentation as an easier, and in know how to provide readable precise documenta-
some sense more important, topic, than verification. tion of a design, as distinct from an implementa-
To them, documentation is that “blah blah” that you tion. No precise description, other than the detailed
have to write. In fact, unless we can solve the docu- code, is available for review. Design reviews early
mentation problem, the verification work will be a in a project, when they would do the most good, are
waste of time. reduced to chat sessions because there are no de-
tailed design documents to discuss.
In talking to people developing commercial soft-
ware we find that documentation is neglected because “ Much software is produced as a cottage industry,
it won’t speed up the next release. Again, program- where there are no people who could serve as qual-
ified reviewers and there is no funding to hire out-
mers and managers are so driven by the most immi-
side reviewers
nent deadline, that they cannot plan for the software’s
● Software is often produced under time pressure
old age. If we recognise that software aging is inevi-
that misleads the designers into thinking that they
table and expensive, that the first or next release of
have no time for proper reviews
the program is not the end of it’s development, that
● Many programmers regard programming as an
the long-term costs are going to exceed the short term
“art” and resent the idea that anyone could or
profit, we will start taking documentation more seri-
should review the work that they have done. I have
ously. known programmers to quite working because they
When we start taking documentation more serious- resented the fact that their work would be subject to
ly, we ‘will see that just as in other kinds of engineer- review.
ing documentation, software documentation must be For any organisation that intends to maintain its
based on mathematics. Each document will be a rep- software products over a period of years, reviews are
resentation of one or more mathematical relations. essential and must be taken more seriously than is
The only practical way to record the information now usual. In particular, to ameliorate the problems
needed in proper documentation will be to use for- of software aging, every design should be reviewed
mally defined notation. and approved by someone whose responsibilities are
6.3 Second opinions - reviews for the long-term future of the product. Reviews by
In engineering, as in medicine, the need for reviews people concerned with maintenance should be car-
by other professionals is never questioned. In the de- ried out when the design is first proposed and long
sign of a building, a ship, or an aircraft, there is al- before there is code. A discussion of how to review
ways a series of increasingly precise design design documents can be found in [2].
documents and each is carefully reviewed by others. 6.4 Why software aging is inevitable
Although the topic of design reviews is widely dis- Even if we take all reasonable preventive meas-
cussed by software engineering lecturers, it is quite ures, and do so religiously, aging is inevitable. Our
astounding too see how often commercial programs ability to design for change depends on our ability to
are produced without adequate review. There are predict the future. We can do so only approximately

283
and imperfectly. Over a period of years, we will make that time demands for changes and corrections will
changes that violate our original assumptions. Docu- continue to come in. Nipping the growth in the bud is
mentation, even if formal and precise, will never be by far preferable. Retrenchment is always painful.
perfect. Reviews, will bring out issues that the de- 7.2 Retroactive documentation
signers miss, but there are bound to be issues that the A major step in slowing the aging of older soft-
reviewers miss as well. Preventive measures are ware, and often rejuvenating it, is to upgrade the
worthwhile but anyone who thinks that this will elim- quality of the documentation. Often, documentation
inate aging is living in a dream world. is neglected by the maintenance programmers be-
7 Software geriatrics cause of their haste to correct problems reported by
Prevention is always the best medicine, but we still customers or to introduce features demanded by the
have to deal with old software. This section outlines market. When they do document their work, it is of-
several things that can be done to treat software aging ten by means of a memo that is not integrated into the
that has already occurred. previously existing documentation, but simply added
7.1 Stopping the deterioration to it. If the software is really valuable, the resulting
If software has been maintained for some time unstructured documentation can, and should, be re-
without much concern for the issues raised here, a placed by carefully structured documentation that has
marked deterioration will be observed. The first step, been reviewed to be complete and correct. Often,
should be to slow the progress of the deterioration. when such a project is suggested, programmers (who
This is done by introducing, or recreating, structure are rarely enthusiastic about any form of documenta-
whenever changes are made. The principles of design tion) scoff at the suggestion as impractical. Their in-
mentioned earlier, can be used to guide change and terests are short-term interests, and their work
maintenance as well. If a design decision about the satisfaction comes from running programs. Nonethe-
system is changed, the new data structure or algo- less, there are situations where it is in the owner’s
rithm can be hidden (encapsulated) in way that makes best interest to insist that the product be documented
any future changes of that aspect of the system easier. in a form that can serve as a reference for future
Careful reviews must insure that each change is con- maintenance programmers.
sistent with the intent of the original designers, that A pleasant side-effect of documentation efforts is
the original design concept is not violated by the new often, the improvement of the software. The formal
changes. documentation that we recommend requires a de-
Stopping the deterioration is, like many other tailed and systematic examination of the code and of-
things in Software Engineering, much easier to say ten reveals bugs, duplicate or almost alike functions,
than to do. Many companies have allowed cancerous and ways to improve performance. In a recent exper-
growth to go on unchecked in their software, for iment, I asked an undergraduate student to produce
years. When times are good, growth is rapid and there documentation for a piece of software that was no
is no obvious reason to be cautious. The result is that longer functional. The author had left our country.
a single project may exist in many versions, each with Although the student was not asked to find bug, the
subtly different structures and based on slightly dif- systematic analysis necessary to create the formal
ferent assumptions. When the period of rapid growth documentation forced him to look at each routine
is over, every change must be made many times and carefully. He suggested some changes and the soft-
the maintainers get confused by the profusion of al- ware is now functional - and well documented for fu-
most alike versions. Someone has to do a serious ture changes.
study of all of those versions and record the differenc- 7.3 Retroactive incremental modularisation
es. Then a team will have to agree on the proper Although all software experts now admit the im-
structure and all versions will have to be forced into portance of modularisation, and most large programs
that mould. In a time when things are not going well, do have some units that are considered modules, a
it is difficult to get enough staff to do the job properly. good understanding of the principles of modularisa-
New documents must be created and reviewed. The tion is rarely reflected in the code. Modularisation re-
code must then be checked to make sure that it has quires more than simply identifying subroutines, or
been made consistent with these new documents. small groups of procedures and calling them mod-
Such a process might take several years and during ules. Each module must comprise all the programs

284
that “know” (are based on) a particular design deci- fortunately, some of their customers found the
sion that is likely to change. Recognizing things that switches and were able to enjoy the benefits of fea-
are likely to change requires experience, and success- tures that they had not purchased. In spite of this, I
fully hiding or confining knowledge of a design deci- suspect that the software manufacturer was ahead be-
sion to one module requires skills and understanding cause of reduced maintenance costs.
that are rare. Still programmers who understand in- 8 Planning ahead
formation hiding and abstraction can usually find If we want to prevent, or at least slow down, soft-
code segments that should be modules and collect ware aging, we have to recognise it as a problem and
them into units. A consultant, who views the software plan for it. The earlier we plan for old age, the more
with fresh eyes, can often show how the job is done. we can do.
Doing so, greatly eases the future maintenance of the
8.1 A new “Life Style”
code. Often of these improvements can be made at lit-
It’s time to stop acting as if, “getting it to run” was
tle cost as a side-effect of changes that have to be
the only thing that matters. It is obviously important
made anyway.
to get a product to the customer quickly, but we can-
7.4 Amputation
not continue to act as if there were no tomorrow. We
Occasionally, a section of code has been modified must not let today’s pressures result in a crippled
so often, and so thoughtlessly, that it is not worth sav- product (and company) next year. We cannot do good
ing. Large sections can be discarded and replaced by work under stress, especially the constant stress of a
artificial “stumps” which perform the function in 25 year crisis. The industry itself must take steps to
some other way. Amputation is always a difficult and slow down the rapid pace of development. This can
controversial decision. Those who have created the be done by imposing standards on structure and doc-
old code are not willing to admit that it is not worth umentation, making sure that products that are pro-
keeping. Again, consultants are often helpful, if they duced using “short cuts” do not carry the industry
can be fully informed. They don’t have the emotional “seal of quality”.
attachment to the code that the authors might have.
8.2 Planning for change
7.5 Major surgery - restructuring
Designs have to be documented, and carefully re-
When a large and important family of products gets viewed, before coding begins. The programs have to
out of control, a major effort to restructure it is appro- be documented and reviewed. Changes have to be
priate. The first step must be to reduce the size of the documented and reviewed, A thorough analysis of
program family. One must examine the various ver- future changes must be a part of every product design
sions to determine why and how they differ. If one and maintenance action. Organisations that are big-
can introduce modules that hide those differences, ger than a few people should have a professional, or a
agree on (and document) standard interfaces for those department, devoted to reviewing designs for
modules, and then make those changes in the various changeability. They should have the power to veto
versions, one can collapse the versions into a single changes that will get things done quicker now but at
system that differs only in a few modules. Replacing a great cost later.
the old versions with the restructured ones, allows fu-
8.3 If it’s not documented, it’s not done
ture changes to the shared code to be shared by many
If a product is not documented as it is designed, us-
versions. In many situations, the separate versions
ing documentation as a design medium [1], we will
can be combined into one by introducing “switches”
save a little today, but pay far more in the future. It is
that are checked at run-time to determine which ver-
far harder tore-create the design documentation than
sion of behaviour is wanted. This introduces a small
to create it as we go along. Documentation that has
amount of run-time inefficiency but greatly reduces
been created after the design is done, and the product
the size of the maintenance staff. I have seen a few
is shipped, is usually not very accurate. Further, such
organisations that were able to offer what appeared to
documentation was not available when (and if) the
be a broad family of products by distributing a single
design was reviewed before coding. As a result, even
piece of code and setting hidden switches to create
if the documentation is as good as it would have
systems that appear to be quite different. The mainte-
been, it has cost more and been worth less.
nance costs of these organisations are much lower
than they would be if they had separate versions. Un-

285
8.4 Retirement savings plans lems without being aware of the efforts in other in-
In other areas of engineering, product obsolescence dustries. Each industry has developed its own
is recognised and included in design and marketing vocabulary and documents describing the way that
plans. The new car you buy today, is “old hat” to the software should be built. Some have developed their
engineers who are already working on future models. own specification notations and diagraming con-
The car is guaranteed only for a (very) limited time ventions. There is very little cross-communication.
and spare parts are also required to be available only Nuclear Industry engineers discuss their software
for prescribed periods. When we buy a car we know problems at nuclear industry meetings, while tele-
that it will age and will eventually have to be re- communications engineers discuss very similar prob-
placed. If we are wise, we begin to plan for that re- lems at entirely different meetings. To reach its
placement both financially and by reading about new intended audience, a paper on software engineering
developments. The manufacturers show similar fore- will have to be published in many different places.
sight. It is only in the software industry where people Nobody wants to do that (but promotion committees
work as if their product will “live” forever. Every de- reward it).
signer and purchaser of software should be planning This intellectual isolation is inappropriate and cost-
for the day when the product must be replaced. A part ly. It is inappropriate because the problems are very
of this planning is financial planning, making sure similar. Sometimes the cost structures that affect so-
that when the time comes to install or develop a new lutions are different, but the technical issues are very
product, the funds and the people are there. much the same. It is costly because the isolation of-
9 Barriers to progress ten results in people re-inventing wheels, and even
more often in their re-inventing very bumpy and
If we are going to ameliorate the problem of aging
structurally weak wheels. For example, the telecom-
software, we are going to have to make some deep
munications industry and those interested in manu-
changes in our profession. There are four basic barri-
facturing systems, rarely communicate but their
ers to progress in Software Engineering. These are at-
communication protocol problems have many simi-
titudes and assumptions that make it impossible for
larities. One observes that the people working in the
research to make a difference.
two industries often do not realise that they have the
9.1 A 25 year crisis?
same problems and repeat each other’s mistakes.
I first heard the term “software crisis” 25 years ago Even the separation between safety-critical and non
and have heard it used to describe a current problem safety-critical software (which might seem to make
every year since then. This is clearly nonsense. A cri- sense) is unfortunate because ideas that work well in
sis is a sudden, short-term serious emergency. The so- one situation are often applicable in the others.
called “software crisis” is certainly serious, but it is
We need to build a professional identity that ex-
neither sudden nor short-term. It cannot be treated as
tends to people in all industries. At the moment we
if it were a sudden emergency: It needs careful long-
reach some people in all industries but we don’t seem
term therapy. “Quick and easy” solutions have never
to be reaching the typical person in those industries.
worked and will not work in the future. The phrase
9.3 Where are the professionals?
“software crisis” helps in dealing with certain fund-
ing agencies, but it prevents the deep analysis needed The partitioning of people and industries with soft-
to cure a chronic illness. It leads to short-term think- ware problems is a symptom of a different problem.
ing and software that ages quickly. Although we have lots of people who are paid to
write software, we don’t have software engineers in
9.2 “Our industry is different.”
the sense that we have aeronautical, electrical, or civ-
Software is used in almost every industry, e.g. air-
il engineers. The latter groups are primarily people
craft, military, automotive, nuclear power, and tele-
who have received a professional education in the
communications Each of these industries developed
field in which they work, belong to professional soci-
as an intellectual community before they became de-
eties in that field, and are expected to keep up with
pendent upon software. Each has its own professional
that field. In contrast, we find that software in the nu-
organisations, trade organisations, technical societies
clear field is written by nuclear engineers who have
and technical journals, As a result, we find that many
learned a programming language, software in the tel-
of these industries are attacking their software prob-
ecommunications field is written by communications

286
engineers and electrical engineers, software in the au- don’t invent new ideas but, instead, apply,
tomated manufacturing field is written by mechanical demonstrate, and evaluate old ones.
engineers, etc. Programming engineers in those in- (5) We need to make the phrase “software engineer”
dustries do not think of themselves as a profession in mean something. Until we have professional
the sense that aeronautical or nuclear engineers do. standards, reasonably standardised educational
Moreover, they have not received a formal education requirements, and a professional identity, we have no
in the field in which they are now working. We find right to use the phrase, “Software Engineering”.
that engineers who write programs know far to little 11 References
about computing science, but computer science grad-
[1] HESTER, S.D., PARNAS, D.L., UTTER, D. F.,
uates know far too little about engineering procedures
“Using Documentation as a Software Design
and disciplines. I often hear, “anybody can write a
Medium”, Bell System Technical Journal, 60, 8,
program” and it’s true, but programs written in an un-
October 1981, pp. 1941-1977,
professional way will age much more rapidly than
[2] PARNAS, D. L., WEISS, D. M., “Active Design
programs written by engineers who have received an
Reviews: Principles and Practices”, Proceedings of
education in the mathematics and techniques that are
the 8th International Conference on Software
important to program design, [8]
Engineering, London, August 1985. Also published
9.4 Talking to ourselves in Journal of Systems and Software, December 1987.
Researchers have to start rethinking their audience. [3] VAN SCHOUWEN, A. J., PARNAS, D. L.,
All too often, we are writing papers to impress our MADEY, J., “Documentation of Requirements for
colleagues, other researchers. Even worse, if we try to Computer Systems”, presented at RE ’93 IEEE
write a paper for the practitioner, the referees com- International Symposium on Requirements
plain if we include any basic definitions or problems. Engineering, San Diego, CA, 4-6 January, 1993.
We end up writing papers that are read by our fellow [4] PARNAS, D. L., MADEY, J., “Functional
researchers but not many others. We also spend too Documentation for Computer Systems Engineering
little time finding out what the practitioners know, (Version 2)”, CRL Report 237, CRL-TRIO McMaster
think, and need. In Faculties of Engineering, profes- University, September 1991, 14 pgs. (to be published
sional practice is recognised as essential to good in Science of Computer Programming)
teaching and research. In many Science faculties, it is [5] PARNAS, D, L., “Tabular Representation of
viewed simply as a way to make some extra money. Relations”, CRL Report 260, CRL. McMaster
This is one of many reason why I believe that Com- University, October 1992, 17 pgs.
puter Science Departments would function better if [6] JANICKI, R., “Towards a Formal Semantics of
they were always part of an Engineering Faculty. Tables”, CRL Report 264. CRL McMaster University,
10 Conclusions for our profession September 1993, 18 pgs.

(1) We cannot assume that the old stuff is known and [7] ZUCKER, J. I., “Normal and Inverted Function
Tables”, CRL Report 265, CRL, McMaster
didn’t work. If it didn’t work, we have to find out why.
Often it is because it wasn’t tried. University, December 1993, 16 pgs.
[8] PARNAS, D. L., “Education for Computing
(2) We cannot assume that the old stuff will work.
Professionals”, IEEE Computer, vol. 23, no. 1,
Sometimes widely held beliefs are wrong.
January 1990, pp. 17-22.
(3) We cannot ignore the splinter software
[9] PARNAS, D. L., CLEMENTS, P. C., WEISS,
engineering groups. Together they outnumber the
D.M., “The Modular Structure of Complex Systems”,
people who will read our papers or come to our
IEEE Transactions on Soflware Engineering, March
conferences.
1985, Vol. SE-11 No. 3, pp. 259-266. Also published
(4) Model products are a must. If we cannot illustrate
in Proceedings of 7th International Conference on
a principle with a real product, there may well be
So@are Engineering, March 1984, pp. 408-417.
something wrong with the principle, Even if the
principle is right, without real models, the technology
won’t transfer. Practitioners imitate what they see in
other products. If we want our ideas to catch on, we
have to put them into products. There is a legitimate,
honorable and important place for researchers who

287