The Laws of Software Evolution

1. The Laws of Software Evolution Tori Bowman CSSE 375, Rose-Hulman September 25, 2007 *based on Don Bagert’s lesson

2. State of 375 • What’s due? • Thursday: Status report (documents due Wednesday) • Friday: Project help (testing & packaging) • This • Legal discussion: F/OSS

3. References • The Laws of Software Evolution Revisited by M. M. Lehman, 21 January 1997

4. Outline • Background • The Laws of Software Evolution • Why does Lehman call them “Laws”? • FEAST – A feedback system for software evolution

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

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

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

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

9. 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 re-engineering and other techniques) this means less effort for new functionality.

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

11. 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 Man-Month by Fred Brooks.)

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

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

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

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

16. 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…

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

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

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

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