The system is not flexible with respect to changes
The system is not flexible with respect to changes. Changes cost more than is necessary, and affect more of the code than they should.
It is possible to build flexibility in to a design, or alternatively to make the changes when they occur. The approach to choose varies considerably. Traditionally the cost of change has been high, so much effort has been made to get the design right first time and build flexibility in to the system from the outset. Unfortunately, not all the flexibility will be needed, and it is expensive to predict, build and maintain flexibility. The cost of unnecessary built-in flexibility needs to be balanced against the cost of unpredicted change. Modern approaches have been reducing this latter cost, so where these approaches can be used, we can reduce the amount of effort spent on unnecessary built-in flexibility. Flexibility will be built in to the code only when it is found to be needed.
Traditional methods are all based on ‘getting it right first time’ owing to an assumption that the cost of change will be comparatively high. Start by ensuring the requirements do not include any unnecessary rigidity, any unnecessary choice of solution; AskFiveTimesWhy. The flexibility promised by Object-Oriented approaches arises from building the core of the system around aspects that will not change with time. To discover the unchanging concepts, ModelTheDomain. Use this structure to the best advantage; get the ResponsibilitiesInTheRightPlace during ObjectOrientedAnalysis. During design, which if we are headed toward an Object-Oriented language will be ObjectOrientedDesign, select appropriate DesignPatterns to deal with the flexibility we are expecting to need. Use these to separate the concerns and optimize the application of VariationBehindInterface. LooseInterfaces should be used between components where extra flexibility is needed.
Modern Agile methods use ConstantRefactoring, with its enabling approaches of full regression tests (as provided by TestDrivenDevelopment) and CollectiveOwnership, to permit cheap changes to code even where the specific required flexibility was not predicted. This means they cut out all unnecessary support for flexibility because YouArentGoingToNeedIt.