Cost of Change

Maintenance

According to IBM research, between 50-75% of the development cost goes in to maintenance rather than development. It makes economical sense to invest in maintainability from the start and there are many ways to address this.

For every feature, integration and dependency the codebase, necessary test suite and monitoring grows. The bigger it gets the harder it is to predictably change.

You can leverage tactical solutions as in automated dependency management (and you should!). These solutions eventually ends up in manual handling and not at the time of your own choosing, resulting in interrupted deliveries.

The more strategic approach to this in my opinion is continuous decrease of maintenance surface area. If you reduce the number of external reasons why you need to change something, your deliveries becomes more predictable.

Break down every feature, integration and dependency package and evaluate the following:

• Is this feature or integration realizing enough value to motivate it's maintanence cost?
• Is the cost of maintaining this dependency or integration lower than writing and maintaining the functionality we're using from it?

You will most likely need to add some metrics in your service (great!) and talk to the bussiness side (even better!) of your organization to make this evaluation. This is a good investment because it enables you to keep track of this over time and it makes the economics of your software less arbitrary for the developers.

Configuration

Some times the the goal is a moving target and you need the capability for a wide spectrum of outcomes rather than a specific one. Before adding the cost of integrating a CMS, consider doing it with a simple JSON or YAML configuration file bundled with your distribution. You probably have a cheap way to manage this through ansible or other tools. Once your schema is stable and you know what the organizations verified needs are, you can decide if migrating to a CMS is warranted for this capability.

Conclution

By reducing the surface area for maintanence and increasing flexibility through configuration, you have remove most reasons to change the code. From now on, product improvement will be a more common reason for your code to change.