Change is the Constant

There is something peculiar about software. When it idles, it does not rust. While in use, it does not wear down. Nonetheless, from the moment a software system is released, its quality deteriorates and an incessant stream of fixes, patches, and enhancements is required to keep its users satisfied. What’s going on?

Software systems stop meeting the needs they were built to satisfy, not because the software changes, but because the needs change.

Let’s review some of the external drivers for change:

• Innovation: Businesses compete by bringing new or improved products and services to the market. Software supports the production of products and the delivery of services. Business innovation drives software change.
• Cost reduction: Services and products that were once innovative lose their differentiating power when competitors start offering the same for less. In markets where similar products or services compete on price, the operational costs of the software systems that support them become a critical factor. Reduction of operational costs drives software change.
• Regulation: Governments are constantly at work to change laws and regulations, be it for the betterment of society or for propping up the financial system. Such changes in the rules require changes not only in the governmental software systems that enforce them, but also in the software systems of banks, airlines, and other businesses that must comply with these rules. Laws and regulations drive software change.

Such external factors drive software change directly. To make things worse, they also cause change through indirect mechanisms.

The internal complexity of software systems is overwhelming. The program code of a medium-sized software system may easily fill 3000 pages of A4 paper, but does not form a linear story. Instead, all paragraphs are intricately interlinked by cross-references. When making a change to such a complex structure, bugs are inevitably introduced. Thus, the initial change indirectly leads to the need for further changes down the line.

Each software system is dependent on others. For example, a web store depends on a payment system, a database system, an internet browser, several operating systems, and so on. Changes in any of these systems may induce the need for changes in the system that depends on them. Thus, changes in one system propagate to other systems through the network of dependencies among them.

As the pace of change of society and business increases, the need for software change increases. And as software systems become more complex and more interdependent, changing them becomes harder. This is the squeeze that we are in and that software evolution research seeks to alleviate.

Several fundamental challenges need to be met:

• Knowledge dissipation: You cannot change a system that you do not understand. To enable evolution, software developers need to be supported in acquiring an understanding of the code they need to change.
• Entropy: Changing software in an uncontrolled manner will make it more complex. More complex software is harder to change in a controlled manner. To break this vicious cycle, mechanisms are needed to control complexity during change.
• Synchronization: The interdependencies between software systems require that changes be synchronized. Software evolution must be supported with mechanisms that loosen the coupling between systems or automate the propagation of changes from one system to another.

As you will read in this issue, researchers are hard at work to confront these challenges.

As solutions become available, in the form of tools and methods for evolving software, a new challenge arises: How can organizations best apply these solutions to manage the evolution of their software portfolios?

To answer this question, a deeper understanding is needed of the economics of software evolution. Changing a software system, or replacing it, represents an investment of time and resources with potential returns in terms of innovation, cost reduction, or regulatory compliance. The application of new solutions for evolving software will impact the cost, risk, speed, and even the outcome of evolution.

These economic factors must be properly understood, quantified, and combined to support the decision-making process regarding software evolution at the software portfolio level. And one economic principle of software evolution must be understood by all: Software is not built to last; it is built to change.

Joost Visser