Worth a read?
http://www.spdynamics.com/
MSc Software Maintenance
MS Viðhald hugbúnaðar
Fyrirlestur 39
Lehman´s Laws of Software Evolution
17/03/2016
Dr Andy Brooks
1
Case Study
Dæmisaga
Reference
Laws of Software Evolution Revisted, M M Lehman,
Feedback, Evolution And Software Technology project,
FEAST paper mml556, 1997
http://www.doc.ic.ac.uk/~mml/feast2/papers/pdf/556.pdf
17/03/2016
Dr Andy Brooks
2
4.4 The FEAST Hypothesis
• “As complex feedback systems, E-type
software processes evolve strong system
dynamics and the global stability tendency
of other feedback systems.
– Processes adopted, applied, and improved in
industry will naturally evolve positive feedback
to drive organisational growth and negative
feedback controls – checks and balances.”
An E-type system is informally described as a software system that implements
a computer application in the real world.
17/03/2016
Dr Andy Brooks
3
4.4 The FEAST sub-hypotheses
“The software evolution process for E-type
systems constitutes a complex feedback
system.”
II. “Where present, feedback is likely to constrain
the global benefits derived from forward path
changes to the process, however effective they
may appear locally.”
III. “Major improvement requires process
innovation to change system dynamics by
modification to feedback mechanisms.”
I.
17/03/2016
Dr Andy Brooks
4
Causal loop diagram for product sale evolution
example from http://en.wikipedia.org/wiki/System_Dynamics
• The positive feedback (reinforcement R) loop: As more people adopt
the new product, then the word-of-mouth impact becomes stronger.
This positive feedback should further generate sales.
– “This was a great buy at $20.”
• The negative feedback ("balancing" B) loop : As more and more
people adopt, there remain fewer and fewer potential adopters.
Growth does not continue forever.
– “I know. I already have one.”
• Initially sales will grow quickly but then later decline.
17/03/2016
Dr Andy Brooks
5
Lehman´s Law VIII
E-type systems constitute multiple-loop, multiplelevel feedback systems and must be treated as
such to be successfully modified.
The diagram represents
feedback loops in project
management e.g. as schedule
pressure goes up then quality
comes down.
Andy asks: What difference to
productivity would it make if we
bought the latest automated
testing tool?
© Gene Bellinger
http://www.systems-thinking.org/prjsys/prjsys.htm
17/03/2016
Dr Andy Brooks
6
Figure 1. The growth of OS/360 Lehman 1980
Chaotic behaviour (releases 1926 ) is said to be due to
“excessive positive feedback in
evolving from release 19 to
release 20.”
"… the ripple (release 1 to 18) is typical of a self stabilising process with
positive and negative feedback loops… the rate of system growth is selfregulatory, despite the fact that many different causes control the selection of
work implemented in each release, with varying budgets, increasing numbers
of users reporting faults or desiring new capability, varying management
attitudes towards system enhancement, changing release intervals and
improving methods…"
17/03/2016
Dr Andy Brooks
7
6 Preliminary Results
Size in Modules
Figure 2. The growth of system FW Lehman 1997
Release Sequence Number
• Logica FW (FastWire) is a banking transaction system with around
one hundred user sites.
• The ripple in the data provides additional evidence that the software
process is self stabilising.
• The growth trend in the data supports the first and sixth laws.
– We do not know from the figure alone whether it is the first or sixth or both laws
that are responsible.
17/03/2016
Dr Andy Brooks
8
Lehman´s Law I (continuing change)
An E-type program that is used in the real world
must be continually adapted otherwise it
becomes progressively less satisfactory.
• Feedback pressure arises from the mismatch between
the software and its operational domain.
• Changes in the operational domain can invalidate
assumptions embedded in E-type software.
– “One of our suppliers has changed the map type of the maps
they provide to our system.”
• The software was built assuming a fixed map type, but now must be adapted
to allow 2 different map types to be imported.
Lehman does not use the term adaptive maintenance.
17/03/2016
Dr Andy Brooks
9
Lehman´s Law VI (continuing growth)
Program functionality must continually increase
to maintain user satisfaction.
• Functionality is often not accommodated (explicitly or
implictly) in the first delivery because of budget
constraints, schedule pressures, technological
limitations, and lack of understanding of the application
in its domain.
– “We do not have time just now to provide a zoom feature.”
• Missing functionality (and other missing attributes)
becomes irritating to the user and leads to demand for
changes.
– “Navigating this large map using only scroll bars is painful. We
really need the zoom feature as in Google Maps”.
• http://maps.google.com/
17/03/2016
Dr Andy Brooks
10
6 Preliminary Results
Inverse square growth law
Ei  ( si  si 1 ) si21
• Turski fitted the above model to the data for the Logica
FW system in Figure 2.
• Si is the size in modules of release i.
• E is a model parameter representing the average of
individual Ei where Ei is said to represent the work done
taking the software system from release i to release i+1.
• An inverse square growth is compatible with the view
that growing complexity (second law) constrains growth.
• (Note that other formulations of Ei exist.)
17/03/2016
Dr Andy Brooks
11
Lehman´s Law II (increasing complexity)
As a program is evolved its complexity increases
unless work is done to maintain or reduce it.
• As changes are implemented, the interactions and
dependencies between system elements increase in an
unstructured way.
– “I´ll just sub-class here. I´ll worry about the conceptual integrity of
the inheritance hirerachy later.”
• Effort expended on combating the growth in complexity
means less effort is available for system growth.
– Time spent re-architecting the design or performing refactoring,
means less time for development.
17/03/2016
Dr Andy Brooks
12
6 Preliminary Results
Inverse square growth law
Ei  ( si  si 1 ) si21
• The graph below illustrates the deviation of the model prediction
from the actual size for Figure 2.
• The fact that its possible to provide a good fit using E appears to
support the third law.
“the ripple”
17/03/2016
Dr Andy Brooks
13
Lehman´s Law III (self regulation)
“the ripple”
The program evolution process is self regulating
with close to normal distribution of measures of
product and process attributes.
• Attributes are said to be, at least in part, normally distributed “being
the consequence of a large number of pseudo independent
managerial and implementation decisions”.
• Note that a later statement of this law makes no claims as to the
nature of the distributions of attributes.
• Note that there is a tendency towards normally distributed data via
the Central Limit Theorem. The distribution of average values tends
towards normality as the sample size used to compute an average
increases. A simulation of this phenomenon is available here:
– http://onlinestatbook.com/stat_sim/sampling_dist/index.html
17/03/2016
Dr Andy Brooks
14
Lehman´s Law IV (organisational stability)
The average effective global activity rate on an
evolving system is invariant over the product
life time.
• Corporate and local management may control resource allocation
(with the aim of modifying the rate of activity), but their ability to
achieve the desired effect is often compromised.
– It might not be possible to recruit additional developers with the right experience.
– New, inexperienced recruits require training, so that their impact on the activity
rate will not be felt for some time,
– Increasing the size of a development team can increase communication
overheads so that there is little change to overall productivity.
– Development staff working too much overtime can suffer from burnout.
• “In any practical situation the level of activity is not decided
exclusively by management edict... Project data so far analysed
suggests that in practice this leads to a stabilisation at a fairly
constant level.” (The E constant in the inverse square model fit.)
17/03/2016
Dr Andy Brooks
15
Lehman´s Law V (conservation of familiarity)
Incremental change in each release is
approximately constant.
(mml613 report wording of this law)
• A team of developers can only comfortably process so many
changes and additions.
• If the team is asked to process changes and additions at a
greater rate then quality will suffer, as it becomes increasingly
difficult to understand what is required. Above a certain
threshold, behaviour changes may be triggered.
– quick-fix maintenance or pragmatic maintenance
• “This works, but I don´t fully understand the code.”
• “I should refactor at this point, but I don´t have time.”
17/03/2016
Dr Andy Brooks
16
Linear or inverse square growth?
Logica FW data, linear fit
3000
Size in Module
Size in Module
• Does growing complexity eventually constrain growth? If so, we
expect an inverse square growth model to be a better fit.
• In earlier work (mml568), Lehman and his co-workers found no
statistical difference in the quality of fits between a linear and nonlinear model for the Logica FW data. “Occam´s razor” tells us to use
the simplest explanation rather than invoke the more complex
explanations. Also, the non-linear fit cannot explain the two outliers.
2500
2000
1500
2500
2000
1500
1000
1000
500
500
0
Logica FW data, non-linear fit
3000
0
0
17/03/2016
5
10
15
20
25
release sequence number
Dr Andy Brooks
0
5
10
15
20
25
release sequence number
17
Really explaining software evolution
• If growth is linear, then the simplest explanation is that each release
increment is work done by a fixed-sized team in increasing functionality,
whether it be perfective maintenance (e.g. customer feature requests) or
adaptive maintenance (e.g. additional device drivers) or both.
• If growth is non-linear, there are many possible alternative explanations
other than that complexity constrains growth.
– Management decreases the number of team members.
– Experienced team members leave to be replaced by in-experienced team members.
– Initial linear growth may reflect a constant work-rate to work through the backlog of
features requested by customers who used the first release. Later, less attention
needs paid to perfective maintenance and more attention to corrective maintenance.
• Andy says: To really explain software evolution requires many types of
data gathered over time and a complete systems dynamics model.
– Team size and composition. Change requests categorized by type (corrective,
adaptive, perfective, preventive). Management of change requests. Etc.
17/03/2016
Dr Andy Brooks
18