Every now and again, I get the chance to collect yet another evidence of the existence of a phenomenon that can expose the true quality of a certain piece of software: The fear of change. We are working in a dynamic business and technological environment. In such an environment, change is sometimes the only constant. Yet, it is not as rare as one would expect to find people, groups, and even entire organizations that do not welcome changes. When I talk about changes in this context, I do not refer to ongoing and extreme changes in the requirements. Such often changes (which eXtreme Programming claims we should embrace) are thoroughly discussed in the article Requirements Instability. What I call the “Fear of Change” is a more fundamental rejection of changes; even changes that are part of the natural evolution of a product are not gladly implemented. Fear of change could appear in various contexts. Here are just a few examples: The development team is not excited to implement a new feature in their product. Developers are worried about porting an existing product to a new platform. System engineers are reluctant to use new technology. Developers tend to stick to old (sometimes obsolete) service components instead of replacing them with better ones. People are afraid of an organizational change that might cause them to interact with new people. Developers are afraid to change the internal structure of the code, even though something is clearly wrong. If you find all the above examples unfamiliar, you are probably working in a very healthy and mature organization. However, chances are that you came across at least one of these scenarios, or a similar one. Naturally, not all changes should be automatically implemented. But when you are facing colleagues who repeatedly reject (or disapprove) changes, something is clearly wrong. In most of cases, the one disapproving of the change has a “very good” reason for doing so. The most common reason for rejecting changes is a poor quality product. Now, I am not talking about a product that fails to meet its functional requirements. I am talking about a product that passed all the functional tests in spite of its poor quality. Poor source code, for example, could generate a product that complies with the functional requirements, but which is a maintenance nightmare. The author of such source code is not likely to be thrilled of implementing additional features in the product or changing some aspect of the implementation. If the developer who should implement the change is not the original author of the code, the situation gets worst. The new developer who should maintain the code might not understand all aspects of the source code. The code could be cryptic to an extent that there is no chance to fully understand it in a reasonable effort. This is the ultimate reason to avoid changes: how can you change something you do not fully understand? The poor design might have a similar effect. If the product was poorly designed, it might be a risky task to replace some service component with a new one. The developer of such a poorly designed product will do anything to avoid replacing the “good old” component. Another kind of problem that might motivate fear of changes is poor testing. If you do not have a good and automatic regression test for the product, every change in its implementation becomes a major risk. The same applies both to QC and to developer tests. A developer who created an extensive set of unit tests to accompany her product will be confident in any changes she might be required to implement in it. As a general conclusion, chronic “Fear of Change” is a clear symptom of poor quality. A developer scared of introducing changes to her creation is insecure with her product. Most of the time, such insecurity has very good reasons to emerge. The problem with fear of change is that if the change is finally implemented, no one seems to remember the original reaction towards it. In such a case, the quality of the product remains poor. Sometimes, it might even get worst, because the change was implemented as a patch in a way that avoids the real problems in the product. It is better to use the fear of change as a warning sign. If you are facing a “Fear of Change” case, you would be better starting to examine the internals of the product, trying to find out the real reasons for rejecting the change. Overcoming the local resistance without a thorough investigation of the symptom’s origins will come to haunt you in the future, as new features, components or platforms will have to be introduced. A final note about the sociology of the “Fear of Change” phenomenon: fear of change always starts at the single person level, but it could rapidly infect entire teams and organizations. It is common to see an entire team unwilling to introduce a change to a product. The reason is that poor quality is seldom local. Various parts of a product implemented by the same team are likely to be of the same quality. So the fact that it is not a single person who rejects a potential change does not necessarily suggest the rejection is justified.
