Software Aging By David Lorge Parnas

1
Software AgingBy David Lorge Parnas
Source Software Findamentals Collected papers
by David L. Parnas. Edited by Daniel M. Hoffman
and Davic M. Weiss
2

• Do software systems age analogously to human?
• What Nonsense!
• Software is a mathematical product mathematics
  doesnt decay with time
• If a program is correct today, it will be correct
  100 years from now
• If it is wrong 100 years from now, it must have
  been wrong when it was written
• It make no sense to talk about software aging
• TRUE, BUT NOT REALY RELEVANT
• Software does get old and it costs more in old
  age than it did at birth.

3

• Do software systems age analogously to human?
• What Nonsense!
• Software is a mathematical product mathematics
  doesnt decay with time
• If a program is correct today, it will be correct
  100 years from now
• If it is wrong 100 years from now, it must have
  been wrong when it was written
• It make no sense to talk about software aging
• TRUE, BUT NOT REALY RELEVANT
• Software does get old and it costs more in old
  age than it did at birth.

4
Software products do exhibit a phenomenon that
closely resemble human aging. Many products are
now viewed as a burdensome legacy from the past.
A steadily increasing amount of effort is going
into the support of these older products. Like
human aging, software aging is inevitable, but
like human aging, there are things that we can do
to slow down the process and sometimes even
reverse its effects. The fact that software is
now becoming a major capital of many high-tech
firms. The aging of these products is impeding
the further development of the systems that
include them.
5

• What causes software aging?
• Two basic types of software aging
• Failure to keep up with changing environment
• Unless software is frequently updated, its
  users will become dissatisfied and they will
  change to a new product as soon as the benefits
  outweigh the costs of retaining and converting
• Tissue damage resulting from maintenance
• It is essential to upgrade software to
  prevent aging, changing software can cause a
  different form of aging. But changes made by
  people who do not understand the original design
  concept almost always cause the structure of the
  program to degrade.

Both lead to a decline in the value of a software
product
6

• Causes of software aging
• Our expectations have changed
• We are no longer willing to use the clumsy
  software interfaces of yesterday
• We demand interactive access
• Old software would still do its job if used, but
  nobody would use it
• Old software must compete with new products
• When changes are not made, it seems as if the
  software has aged!

7

• More causes of software aging
• Designers of software had simple concept in mind
  when writing the program
• Changes made without understanding design concept
  
• Changed code is inconsistent with original
  concept
• After changes, one must know both the original
  design concept, and the exceptions
• After more changes NOBODY understands the
  modified product
• When nobody understands the product
• Changes take longer
• Changes are more likely to introduce bugs
• The problem is exacerbated when maintainers do
  not have time to update the documentation

8
More causes Many companies allow the product
line to split, with the second line inheriting
the properties of the first. This policy leads
to difficult to constrain, growth. Changes must
be made to many versions instead of just one The
cost of maintenance gets very high, it is no
longer possible to keep up with the market on all
the versions. Plus Developers move on to other
projects Developers forget what they did and why
they did it
9

• More Causes
• Bad documentation
• Information not available
• Information not correct
• Information hard to find
• Information must be verified
• Information is not precise, easily misinterpreted
• Documentation are not kept alive

10

• The costs of software aging
• Rising Maintenance Costs
• It harder to know where to make changes
• Changes are harder to make
• There are more errors
• Testing becomes more of a burden
• Documentation takes longer to update

11

• Inability to keep up with others
• Newer products have desired features
• Newer products can be adapted more quickly
• Newer products win more market share
• Program size increased order of magnitude makes
  changes more difficult

12

• Reduced performance
• The size of the program grows more demands on
  the computer resource
• More demands on the computer memory, more delays
  caused by swapping
• Performance decreases because of poor (or poorly
  understood) design
• Customers must upgrade their hardware to get
  acceptable response -- leads to switch to newer
  products to obtain better performance

13

• Decreasing reliability
• Errors are introduced each error corrected may
  introduce more than one error
• Improvements can make things worse -- often the
  only choice was to abandon the product or at
  least to stop repairing bugs
• Large groups of people are devoted to customer
  requested repairs

14
Reducing the costs of software aging Experience
showed that any serious product requires
extensive testing, review and revision after the
first successful run. The work that is invested
by a development organization after the first
successful run and before the first release is
usually much greater than that required to get
the first successful run. Most organization only
focus on that first release Experience with
software aging tells us that we should be looking
far beyond the first release to the time when
product is old.
15
What can we do to delay the decay and limit
software agings effects Design for success The
only software that does not change is software
that is not used. Designing for change is
designing for success Apply Information
hiding Abstraction Separation of concerns Data
hiding Object orientation By characterizing the
likely classes changes estimate the
probabilities of each type of change Organize the
software to confine likely changes to a small
amount of code Implement objects that hide
changeable data structures Provide an abstract
interface that abstracts from the changes
16
Why the industry failed to apply these
ideas? Programmers are impatient with such
considerations they are eager to meet deadline,
there is no time to design for change Designs
that result from a careful application of
information hiding are not natural for many
software designers Designers mimic older
designs Many confuse design principles with
choice of language Many developers do not have
the education appropriate to the job
17

• There is no miracle drugs or quick fix to this
  problem
• Good design is HARD, it requires
• Careful consideration of possible changes
• Careful examination of constraints
• Careful design of interface
• Careful review
• Qualified people

Do not depend on languages, we must recognize
that software problems never went away in spite
of the introduction of FORTRAN, PL/I. ADA
18

• Keeping records Documentation
• Design concepts and decisions are not recorded
• Documentation is neglected by researchers and
  practitioners
• Documentation is usually poorly organized,
  incomplete and imprecise
• Often the coverage is random, written when time
  and interest are there
• Where documentation is a contractual requirement,
  its often done by a technical writer who does
  not understand the system
• Documentation that seems clear today, may be
  difficult to understand tomorrow

Documentation is not an attractive topic. But
it is your responsibility as a software engineer
to produce accurate design document and to keep
them up-to-date
19

• Second Opinions reviews
• Reviews are not standard practice among
  developers, why?
• Many developers have no professional training in
  software and the concept of preparing and holding
  a design review is non-existent
• Lack of documentation is review against
• Software is often produced under time pressure,
  leads to short-cut
• Reviewer must represent long-term interests of
  the manufacturer or client
• Review for ease of change must become standard

20

• Software aging is inevitable
• Our ability to design for change depends on our
  ability to predict the future
• We will make changes that violate our original
  assumptions
• Documentation, even if formal and precise, will
  never be perfect
• Reviews will overlook some issues
• Preventive measures are worthwhile, but we cannot
  eliminate aging
• We have to think about how to care for aging
  software!

21
How to care for aging software Stopping the
deterioration This is done by introducing, or
recreating structure whenever changes are made.
Applying the same design principles, if a design
decision about the system is changed, the new
data structure or algorithm can be
hidden(encapsulated) in a way that make any
future changes of that aspect of the system
easier. Careful reviews must ensure that each
changes is consistent with the intent of the
original designers. New documents must be
created and reviewed The code must be checked to
make sure that it has been made consistent with
these new documents
22
Retroactive documentation To slow the aging
upgrade the documentation! Correcting the
documentation can be a major project, but worth
undertaking Redoing the documentation often
leads to improvements in the software Writing
the documentation is a way to study and
understand the software It makes the next
persons job easier
23
Amputation Some code has been modified so often
and so thoughtlessly, it is not worth
saving. Often it should never have been written
at all Sections of code should be discarded and
replaced by new code which perform the function
in some other way.
24
Restructuring When a large family of products
gets out of control, a major effort to
restructure it is appropriate. First step
reduce the size of the program Examine the
various versions to determine why they are
different Replace many versions with one by
introducing switches that are checked at
run-time to determine which version of behavior
is wanted. It often pays to ship the same code
to everyone even those who have not paid for
all the features .. The features can be turned
off
25
Planning ahead If we want to prevent or at least
slow down software aging, we must recognize it as
a problem and plan for it. We must imposing
standards on structure and documentation Design
have to be documented, reviewed before coding
begins Changes have to be documented and
reviewed A thorough analysis of future changes
must be a part of every product design and
maintenance action