Lehman’s research project is a an attempt to understand the process of software evolution. The first attempt was in the end of the sixties (Lehman, 1969), where he described the evolution of IBM’s OS/360.
He uses a relationship which is the same as Rosen’s (1985) where E-programms as he calls them model a real-world domain:
“all programs that, when executed in a specified real world domain (the execution domain), solve a problem (or set of problems) defined in and part of that domain”
>But since the real world changes, there is an inevitable disrepancy between the program and the real world. The problem is also caused by the indedeterministic behaviour of hunman agents, making its formalization impossible (see also the Pole A - Pole B continuum). In order to keep their behaviour adequate (law of requitsite variety (Ashby, 1962)), programs must aquire more functions, becoming more complex in the process: “Growing complexity is reflected by increased size, more interdependent functionality, a larger number of integrated components, more control mechanisms,a higher level of reciprocal interdependency.” One cannot help but notice the similarity of this account with Salthe’s (1993) four phenomenological rules for complex systems and the resulting stages of development (immature, mature, senescent).
Such increase brings with it,pressure for a decline in the attainable functional growth rate [e.g. leh98]. Managers can either ignore this decline and face the inevitable consequences of eventual system stagnation. Alternatively they can take cognisance of the complexity growth and divert effort to control it and any other forces causing the decline in growth rate. Given an awareness that growth trends that constrain system evolution develop, they may well accept the need to direct effort to activities that might otherwise have been overlooked or neglected.
observations indicate directly that the average software growth rate measured in modules or their equivalent tends to decline as a function of the release sequence number as the system ages. The long term trend tends to follow an inverse square trajectory with the mae (mean absolute error), that is the mean absolute difference, between release sizes as predicted by the model and their actual size of order 6%.
One solution to the problem (also known as Big Ball of Mud ), is to focus on a modular structure (Brand so that the evolution of outer layers (which must respond to the quickly changing environment), does not break inner ones. See also my Moving Target: Designing for Evolving Practice paper that deals exactly with this issue.
References
- Ashby, C. R. (1962). Requisite Variety and its Implications for the Control of Complex Systems. General Systems Yearbook, 9, 99-105.
- Brand, S. (1994). How Buildings Learn. New York: Viking.
- Lehman, M. M. (1969). The Programming Process. In Program Evolution - Process Software Change: Academic Press.
- Rosen, R. (1985). Anticipatory Systems. Oxford: Pergamon Press.
- Salthe, S. N. (1993). Development and Evolution: Complexity and Change in Biology. Cambridge: MA: MIT Press.
Leave a Reply