Cost of Change – The Fear Factor

Oren has blogged on how to reduce the cost of change. He claims and I agree that

Beyond anything else, it is the will of the team to accept the pain of making the change and actually doing this

When accepting this mind set its usually a lot easier to find ways of reduce the change cost . i.e. make it easier to change.

However I feel there’s another factor in equation, and that is the developer’s inherent fear of the unknown. Time and time again I’ve seen (and did that myself) programmers start implementing a change by attacking its easier parts first, leaving the real hard unknown issues to the end.

When adding a new functionality to an existing system for example, there are two main steps:

1. Implementing the new functionality.
2. Integrating it into the given system.

In most cases the harder part will be the second part, however 90% of the times a programmer natural instinct would be to start out with coding the new functionality.

As far as I could tell, the reason is that in most cases the new functionality is kind of a well defined problem, while the effect of the integration part is a big unknown, and most people will shy away from uncertainties leaving it to the end. and if we add to this the general “embedded”dislike of changing existing code (if it works don’t fix it) and we get the natural tendency to start with the well understood isolated new piece of code.

The problem is that in most cases the hard parts are, well, hard. They are the parts that will lead to the real problems which will take time to solve. Starting out with the easier parts of a problem leads to a false sense of progress which later on may bite when facing the real difficulties in the implementation.

Here's an example of such  a thing happening, in this case we have worked on a feature for quite some time, but were only able to complete it after starting all over again by attacking the hard integration issues first.

So don’t make the natural Mistake of letting fear of the unknown take over. Accept the fact that the hard problems are there and must be solved. and start by solving them first. When that’s done the easier parts will easily fall into place.

Posted in: Development Practices,Random Thoughts