Feature Anyone who has worked in medium or large organisations will know that there are three levels of change control when it comes to code: (a) the organisation doesn’t have any, (b) the organisation has change control but does it sub-optimally, and (c) change is managed well.
Anyone who has worked under more than one of these three levels will have seen that the closer you get to (c), the less change-induced disruption you experience. And yes, this probably sounds like common sense, but as with many aspects of real life, common sense turns out not to be as common as you’d like.
Example 1
Take company A as an example. The IT department had one of the most skilled, capable teams one could ever encounter – roles were well defined and each of the senior engineers was at the top of his or her game for the fields in which they worked. Yet things kept breaking, so senior management decided to see what was going wrong.
The core problems turned out to be twofold. First, changes that were being made were not planned very well – particularly with regard to how a change would be backed out if something unexpected went wrong. So, in the event of a problem, the engineers would have to think on the hoof to get things back up and running.
Second, any unexpected impact was often not with the thing that was being changed, but something completely different: something that wasn’t in the test plan and whose issues weren’t spotted until the next morning when a user of that…
