16/05/2015Dr Andy Brooks1 MSc Software Maintenance MS Viðhald hugbúnaðar Fyrirlestur 39 Lehman´s Laws of Software Evolution Worth a read?

16/05/2015Dr Andy Brooks2 Case Study Dæmisaga Reference Laws of Software Evolution Revisted, M M Lehman, Feedback, Evolution And Software Technology project, FEAST paper mml556,

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.” 16/05/2015Dr Andy Brooks3 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.” 16/05/2015Dr Andy Brooks4

Causal loop diagram for product sale evolution example from 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. 16/05/2015Dr Andy Brooks5

16/05/2015Dr Andy Brooks6 © Gene Bellinger 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 /05/2015Dr Andy Brooks7 "… 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 ) 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. 16/05/2015Dr Andy Brooks8 6 Preliminary Results Size in Modules 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. 16/05/2015Dr Andy Brooks9 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”. 16/05/2015Dr Andy Brooks10 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. S i is the size in modules of release i. E is a model parameter representing the average of individual E i where E i 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 E i exist.) 16/05/2015Dr Andy Brooks11 6 Preliminary Results

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. 16/05/2015Dr Andy Brooks12 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. 16/05/2015Dr Andy Brooks13 6 Preliminary Results “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: – 16/05/2015Dr Andy Brooks14 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.) 16/05/2015Dr Andy Brooks15 Lehman´s Law IV (organisational stability) The average effective global activity rate on an evolving system is invariant over the product life 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.” 16/05/2015Dr Andy Brooks16 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. 16/05/2015Dr Andy Brooks17

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. 16/05/2015Dr Andy Brooks18