18/04/23 Dr Andy Brooks 1

MSc Software MaintenanceMS Viðhald hugbúnaðar

Fyrirlestur 39Lehman´s Laws of Software Evolution

Worth a read?

http://www.spdynamics.com/

18/04/23 Dr Andy Brooks 2

Case StudyDæmisaga

ReferenceLaws 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

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.”

18/04/23 Dr Andy Brooks 3

An E-type system is informally described as a software system that implements a computer application in the real world.

4.4 The FEAST sub-hypotheses

I. “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.”

18/04/23 Dr Andy Brooks 4

Causal loop diagram for product sale evolutionexample 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.

18/04/23 Dr Andy Brooks 5

18/04/23 Dr Andy Brooks 6

© Gene Bellingerhttp://www.systems-thinking.org/prjsys/prjsys.htm

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?

Lehman´s Law VIII E-type systems constitute multiple-loop, multiple-level feedback systems and must be treated as such to be successfully modified.

Figure 1. The growth of OS/360 Lehman 1980

18/04/23 Dr Andy Brooks 7

"… 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 self-regulatory, 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…"

Chaotic behaviour (releases 19-26 ) is said to be due to “excessive positive feedback in evolving from release 19 to release 20.”

Figure 2. The growth of system FW Lehman 1997

• 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.

18/04/23 Dr Andy Brooks 8

6 Preliminary Results

Release Sequence Number

• 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.

18/04/23 Dr Andy Brooks 9

Lehman does not use the term adaptive maintenance.

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.

• 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/

18/04/23 Dr Andy Brooks 10

Lehman´s Law VI (continuing growth)Program functionality must continually increase to maintain user satisfaction.

Inverse square growth law

• 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.)18/04/23 Dr Andy Brooks 11

6 Preliminary Results

21 1( )i i i iE s s s

• 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.

18/04/23 Dr Andy Brooks 12

Lehman´s Law II (increasing complexity)As a program is evolved its complexity increases unless work is done to maintain or reduce it.

Inverse square growth law

• 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.

18/04/23 Dr Andy Brooks 13

6 Preliminary Results

21 1( )i i i iE s s s

“the ripple”

• 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

18/04/23 Dr Andy Brooks 14

Lehman´s Law III (self regulation)The program evolution process is self regulating with close to normal distribution of measures of product and process attributes.

“the ripple”

• 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.)

18/04/23 Dr Andy Brooks 15

Lehman´s Law IV (organisational stability)The average effective global activity rate on an evolving system is invariant over the productlife time.

• 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.”

18/04/23 Dr Andy Brooks 16

Lehman´s Law V (conservation of familiarity)Incremental change in each release is approximately constant.(mml613 report wording of this law)

Linear or inverse square growth?• 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 non-linear 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.

18/04/23 Dr Andy Brooks 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.

18/04/23 Dr Andy Brooks 18