“On Understanding Laws, Evolution, and Conservation in the Large-Program Life Cycle”, 1979 ():
[WP; commentary, cf. ball of mud] The paper presents interpretations of some recently discovered laws of evolution and conservation in the large-program life cycle. [based in part on OS/360 IBM studies]
Program development and maintenance processes are managed and implemented by people; thus in the long term they could be expected to be unpredictable, dependent on the judgments, whims, and actions of programming process participants (eg. managers, programmers, and product users). Yet, observed, measured, and modeled regularities suggest laws that are closer to biological laws or those of modern physics than to those currently formulated in other areas subject to human influence (eg. economics and sociology).
After a brief discussion of the first 4 laws, to highlight underlying phenomena and natural attributes of the program evolution process, the paper concentrates on a fifth law and shows how, and why, this law represents a conservation phenomenon: the Conservation of Familiarity.
The 5 Laws of Program Evolution:
A program that is used and that, as an implementation of its specification, reflects some other reality, undergoes continuing change or becomes progressively less useful. The change or decay process continues until it is judged more cost effective to replace the program with a recreated version.
As an evolving program is continuously changed, its complexity, reflecting deteriorating structure, increases unless work is done to maintain it or reduce it.
The Fundamental Law (Of Program Evolution).
Program evolution is subject to a dynamics which makes the programming process, and hence measures of global project and system attributes, self-regulating with statistically determinable trends and invariances.
Conservation Of Organization Stability (Invariant Work Rated)
The global activity rate in a project supporting an evolving program is statistically invariant.
Conservation Of Familiarity (Perceived Complexity)
The release content (changes, additions, deletions) of the successive releases of an evolving program is statistically invariant.
…Good intentions, hopes of correctness, wishful thinking, even managerial edict cannot change the semantics of the code as written or its effect when executed. Nor can they after the fact affect the relationship between the desires, needs, and requirements of users and the program…implementation; nor between any of these and operational circumstances—the real world.
…A widely held view is that the details of a desired change need “only” be written down and then applied without further real effort to all instances of the system. As a consequence, changes are superimposed in a current embodiment. This contrasts strongly with normal industrial practice where conceptual changes are inputs to a redesign and recreation process that ultimately produces a new instance of the system.