As software developers, we know that our systems will evolve with time. We must understand the forces that drive this evolution, in order to design systems that are easily evolvable. Unfortunately, many programmers have misconceptions about the real drivers of software evolution and about their own ability to predict how a system will evolve.
In my many years of experience as a professional software developer I had the luck to work on many projects from start. But on other occasions I joined projects that were already mature and deployed to real users. In these projects I observed the difficulty to maintain systems that were not planned for change. I condense my personal experience below in the form of four myths of software evolution.
Myth 1 – Changes are driven by improvements in implementation
Very often programmers believe that they will only have to change their code if they think about a better way to implement it, but this is not true. Most modifications are caused by new requirements originating from real users, who are not satisfied with the current functionality. For this reason, it is always more important to invest time understanding the user requirements than optimizing your algorithms.
Reality: Changes are driven by better understanding of user requirements.
Myth 2 – If you did your best, you will not need to change it
Many programmers are perfectionists; they will try to do their best and only be happy with a piece of code if they feel they cannot improve it. However, any code can be improved when these improvements originate from new user requirements. The idea of a “best possible code that cannot be improved” is a dangerous illusion. It is dangerous because it focuses on the quality of the implementation details, and not on the satisfaction of user needs.
Reality: Even if you did your best, you can still improve it.
Myth 3 – After many improvements, the code will not be changed again
Some programmers believe that if they have already invested a considerable amount of time improving a piece of code, it has reached a “stable” state in which it will not be necessary to change it again. However, the truth is that the number of changes is always proportional to the usefulness of the code. When people use your code they discover the need for new functionalities, which is the main source of changes. Thus if your code has been changed a lot in the past, it is probable that it will need to be changed again.
Reality: The more a code is used, the more it will need to be changed.
Myth 4 – You can predict which parts of the system will need to be changed
It is not possible to predict the new requirements originating from real users. The best we can do is to identify the components that play the most central role in the functionality of the system, and to design them to accommodate easily the future changes in requirements. Of course the system may also need to be changed to improve its performance, but this should be done after appropriate profiling of real usage and identification of the bottlenecks.
Reality: Evolution cannot be predicted. The users will always be able to surprise us.
The conclusion from the myths above is that when you know that a piece of code is important and will have many users, the best you can do is to design for maintainability. In other words, if a component is likely to be changed, it is more important to design it to be easily modified than to implement it perfectly using the more efficient algorithms.
Now you can ask two questions:
1) How do I design for maintainability? I think that the response is to focus on the Separation of Concerns, keeping low coupling and high cohesion.
2) Which methodology makes evolution easier? I think that Iterative Software Development is the best way to handle constant software evolution.
What do you think about these four myths of software evolution? Do they fit your own experience? Please share your comments below.