The Laws of Software Evolution
Tori Bowman
CSSE 375, Rose-Hulman
September 25, 2007
*based on Don Bagert’s lesson
1
State of 375

What’s due?


Thursday: Status report (documents due
Wednesday)
Friday: Project help (testing & packaging)

This

Legal discussion: F/OSS
2
References
The Laws of Software Evolution Revisited by
M. M. Lehman, 21 January 1997
3
Outline




Background
The Laws of Software Evolution
Why does Lehman call them “Laws”?
FEAST – A feedback system for software evolution
4
Background – 1/2




Relate primarily to perfective change
Developed by M.M. Lehman
The Laws themselves have “evolved”,
from three in 1968 to eight by 1997
Have been empirically demonstrated for at
least two systems:


OS/360 (IBM mainframe OS in the 1960’s)
Logica FW (a financial transaction system)
5
Background – 2/2


Is largely based on the concept of the
existence of positive and negative
feedback systems existing in the software
environment
Examples of feedback systems:




Users
Management
Developers
Government
6
Definitions

S-type software


Definition: those
addressing a problem with
a computational solution in
an abstract and closed, for
example mathematical,
domain
Example: floating point
package may be judged
correct versus the IEEE
standard for floating point

E-type software


Definition: produced
because it satisfies some
real world need and so is
forced to evolve as the
reality changes
Example: embedded code
must fit the hardware it is
placed in and must change
if the hardware is changed
– majority of SW is here
7
The Laws of Software Evolution
I - Continuing Change: An E-type (evolutionary
type) program that is used must be continually
adapted else it becomes progressively less
satisfactory.
This is due in part to the fact that the software
never exactly matches the desired operational
domain (the “Software Uncertainty Principle”).
8
The Laws of Software Evolution
II – Increasing Complexity: As a program is evolved its
complexity increases unless work is done to maintain or
reduce it.


Related to the Second Law of Thermodynamics: “In all energy
exchanges, if no energy enters or leaves the system, the
potential energy of the state will always be less than that of the
initial state." This is also commonly referred to as entropy.
This law exists because as the E-type software is adapted to the
changing operational environment, there is not only an
increasing number of interactions, but an increasing number of
interactions that were adds-on to the original design of the
system. If effort is expended to combat this (through reengineering and other techniques) this means less effort for new
functionality.
9
The Laws of Software Evolution
III – Self Regulation: The program evolution process is
self regulating with close to normal distribution of
measures of product and process attributes.
From Lehman’s paper: “Checks and balances will have
been established by…management to ensure that
operational rules are followed and organizational
goals…are met…[This is] one example of feedback driven
growth and stabilization mechanisms…[They] establish a
disciplined dynamics whose parameters are, in least in
part normally distributed.”
10
The Laws of Software Evolution
IV – Conservation of Organizational Stability (invariant
work rate): The average effective global activity rate
[total effort expended] on an evolving system is invariant
over the product lifetime.
This law on the face of it doesn’t make sense. However,
various forces are at work that often counteracts attempts
to increase productivity e.g. management increasing the
number of people on a project increases communication
overhead. (This was first described in The Mythical ManMonth by Fred Brooks.)
11
The Laws of Software Evolution
V – Conservation of Familiarity: During the active life of
an evolving program, the content of successive releases is
statistically invariant.
From Lehman’s paper: “One of the factors that
determines the progress of a software development is the
familiarity of all involved with its goals. The more
changes & additions [in a] particular release, the more
difficult is for all concerned to be aware, to understand
and to appreciate what is required of them…The larger
the work package the more challenging mastery of the
matter to be acquired.”
12
The Laws of Software Evolution
VI – Continuing Growth: Functional content of a
program must be continually increased to
maintain user satisfaction over its lifetime.
This is not the same as the first law, which refers
to the fact that software never exactly matches
its operational domain. For the sixth law, the
reason is that various factors mean that user
demands for more functionality will increase over
time, and thus the functional content must also
increase.
13
The Laws of Software Evolution
VII – Declining Quality: E-type programs will be
perceived as of declining quality unless rigorously
maintained and adapted to a changing operational
environment.
Otherwise, the system is perceived as older and
less useful.
14
The Laws of Software Evolution
VIII – Feedback System: E-type programming
processes constitute multi-loop, multi-level
feedback systems and must be treated as such to
be successfully improved.
Multi-loop means that it is an iterative process and
multi-level refers to the fact that it occurs in more
than one aspect of the software and its
documentation.
15
Why does Lehman call them “Laws”? - 1/2

From his paper:




Observed phenomena reflected the behavior of human
designers, implementers, managers and users. Thus they could
not be laws in the normal sense of the word
Phenomenology they reflect could be altered at will, by
education for example.
Behavior described was intimately bound up with a particular
organization and/or a particular [operating] system…
As such the observed phenomena lacked the generality that use
of the term law implies…
16
Why does Lehman call them “Laws”? - 2/2

From his paper (continued):




Laws reflect the cooperative activity of many individual and
organizational behavior.
Their analysis requires: experience in disciplines removed from
computer science and software engineering, psychology,
organizational theory and management science
Observed behavior reflects the environment within which
software engineering operates and the laws governing that
behavior are not part of that discipline.
“From the point of view of software engineering they must be
accepted as laws…”
17
FEAST –
A feedback system for software evolution 1/3


FEAST stands for Feedback, Evolution And
Software Technology.
It seeks to investigate the role and
influence of feedback in the evolution of
E-type software systems and on the
improvement of the software process
18
FEAST –
A feedback system for software evolution 2/3
Hypothesis
As complex feedback systems E-type software processes
evolve strong system dynamics and the global stability
tendency of other feedback systems
Supporting observation
Processes adopted, applied and improved in industry,
will naturally evolve positive feedback to drive
organisational growth and negative feedback controls checks and balances
19
FEAST –
A feedback system for software evolution 3/3

Preliminary Results



Were for one particular system
Suggest that the system dynamics is so
strong that its parameters are fixed quite
early in the life cycle of the evolving system
There has been further work since then
http://www.doc.ic.ac.uk/~mml/feast2/papers.html
20