I came across a really interesting paper the other day on the lifecycle of software projects. Much of it resonated with what I see today, which is especially surprising seeing 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". 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 just 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 have a limit to 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 can also only change proportional to its size: small projects can change drastically, large projects cannot (within reason). Software often gets more stable over time as feedback is incorporated back into the system.

A screenshot of the table as it appeared in the paper.