Change is inevitable

Change is inevitable. Chang is Constant. - Benjamin Disraeli 

Change is part of life. This applies to every aspect of life. Software that solves real world problems too is greatly affected by this phenomenon.

Professor Meir Manny Lehman came up with several laws of software evolution. These laws in a way explain the need to learn how to deal with change.

There are 8 laws in total. Here is a summary:

I - Continuing Change
An E-type program that is used must be continually adapted else it becomes progressively less
satisfactory.

II - Increasing Complexity
As a program is evolved its complexity increases unless work is done to maintain or reduce it.

III - Self Regulation
The program evolution process is self regulating with close to normal distribution of
measures of product and process attributes.

IV - Conservation of Organisational Stability (invariant work rate)
The average effective global activity rate on an evolving system is invariant over the product
life time.

V - Conservation of Familiarity
During the active life of an evolving program, the content of successive releases is
statistically invariant.

VI - Continuing Growth
Functional content of a program must be continually increased to maintain user satisfaction
over its lifetime.

VII - Declining Quality
E-type programs will be perceived as of declining quality unless rigorously maintained and
adapted to a changing operational environment.

VIII - Feedback System
E-type Programming Processes constitute Multi-loop, Multi-level Feedback systems and must
be treated as such to be successfully modified or improved

All these laws, relate specifically to E-type systems, that is, to software systems that solve a problem or implement a computer application in the real world.

There laws are sometimes criticized and said to be challenged by open source software development models. However, more often than not, these laws do apply, in my experience.

As an example, take Apache httpd. Form 1.x family to 2.x family, the evolution has shown the impact of the winds of change, specially the increased complexity and the invariant change rate.

If we consider what happened to Apache Axis, Axis2 was designed to overcome Axis1 limitations. Axis2 has been around for more than three years now, but the work rate still remains the same.New issues are found regularly, despite the fact the issues are being fixed at more or less a constant rate. I would not be surprised an Axis3 effort is initiated, given the amount of complexity that Axis2 has embraced over the very short lifetime it has enjoyed on this planet.

Now if one says, no, there is no room for Axis3, it is good enough, and there is no room for Apache3 (httpd) at all, I would have to agree, but if an only if, those are not used in the "real world". If these projects are used in the real world, I strongly believe that there will be a point that a bunch of developers would start working on the third generation of them. Else they will die.

Right now, these projects are alive, because developers and the users alike keep on finding issues and reporting them and more importantly, developers and contributors keep on fixing those issues. And due to these fixes, these projects keep on being more complex, thus quality drops, and to restore quality more work is required. One of the strong points of open source projects is that they have a good feedback system in place, the user and developer communities. 

Our ability to survive depends on our ability to evolve. Evolution is about the ability to deal with change. Either we adopt and live, or die.