I came across a really interesting paper the other day on the lifecycle of software projects. So much of it resonated with what I see today, which is especially surprising that the paper appeared in the IEEE Journal 41 years ago! Meir "Manny" Lehman, the author, laid out five different laws he observed in IBM's programming process, where he worked in the research division. I've copied them here, with a short remark on how I interpret them working in today's developer world.
I. Continuing Change
A program that is used and that as an implementation of its specification reflects some other reality, undergoes continual change or becomes progressively less useful. The change or decay process continues until it is judged more cost effective to replace the system with a recreated version.
This law tells us that a program is never really "done." Instead, requirements continue to change, and programs necessarily bit rot in unexpected ways (see: Software Treadmills).
II. Increasing Complexity
As an evolving program is continually changed, its complexity, reflecting deteriorating structure, increases unless work is done to maintain or reduce it.
Today, we call this technical debt. Software wants to be simple, but continuous changes make complexity monotonic.
III. 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.
Lehman sums it up here with the fundamental law: requirements outside business requirements and market forecasting affect a program's evolution. The people, processes, and software itself all play a large role.
IV. Conservation of Organizational Stability (Invariant Work Rate)
During the active life of a program the global activity rate in a programming project is statistically invariant.
I read this as a result of the Mythical Man-Month: that certain projects limit how many resources can be allocated to them. You might also apply Conway's Law, that product teams ship their organization structure.
V. Conversation of Familiarity (Perceived Complexity)
During the active life of a program the release content (changes additions, deletions) of the successive releases of an evolving program is statistically invariant.
A project changes proportionally: small projects can change drastically, and large projects cannot (within reason). Software becomes more stable over time as feedback is incorporated into the system.
A screenshot of the table as it appeared in the paper.
