Arguably, the best type of maintenance is that which does not need to occur. Adaptability refers to the ability of your code to cater to and adapt to different needs and environments. The code cannot be infinitely adaptive. The very nature of code is that it is made for a specific purpose; to solve a specific problem for the user. We can and should provide a level of configuration in our code, allowing for varying needs, but we cannot foresee all possibilities. Eventually, someone with new requirements may need to come along and make changes to the underlying code.

If we were to create a JavaScript component that displays a carousel of images (a slideshow), it's obvious to imagine that users will want to configure the specific images displayed. We may, for example, also have a configuration option for enabling or disabling the fade-in or fade-out behavior of the carousel. Our complete set of configuration options may look like this:

• (Array) images: The image URLs you wish to display in the carousel
• (Boolean) fadeEffectEnabled: Whether to fade between images
• (Number) imageTimeout: The number of milliseconds a single image will display for
• (Boolean) cycleEnabled: Whether to keep repeating the slideshow

These configuration options define the extent to which our component is adaptable. It can be used in a variety of different ways by wielding these options. If a user wants it to behave in a way that is not made possible by these options, then they may wish to change its behavior by modifying the underlying code. 

When changes need to be made to the underlying code, it is important that they can be made with as little trouble as possible. Two harmful characteristics that might cause trouble are fragility and rigidity:

• Fragility is the characteristic of being brittle whenever changes are attempted. If one area of code is changed to make a bug fix or add a feature, and it affects several seemingly unrelated things in a different part of the code base, then we can say the code is fragile.
• Rigidity is the characteristic of failing to accommodate change easily. If one behavior needs to be changed, ideally, we should only have to make that change in one place. But if we have to rewrite code all over the place just to accomplish that one change, then we can say the code is rigid.

Fragility and rigidity are usually symptoms of larger code bases, where there are many interdependencies between modules. This is why we say that modularity is so important. Modularity refers to the separation of concerns into distinct areas of code in a way that reduces intertwining code paths.

Working to avoid fragility and rigidity is a good goal and will make our code more accommodating to changes, but the most crucial aspect of a code base for a maintainer is its comprehensibility. That is, the extent to which it can be understood. Without understanding what, the maintainer cannot even begin to make changes. In fact, in obscure and confusing code bases, it is sometimes impossible to discern whether changes are even required. This is why we will now be exploring familiarity as an aspect of maintainability. By utilising familiar conventions and intuitive patterns, we can help to ensure a high level of understanding among our maintainers.