Well, I must take exception to the Chris Byrne's post Would You Change Your Oil at 70 MPH?
, which won't surprise him, as I take a certain pleasure in challenging him, no matter what name he is using
at the moment. That's what friends are for, right?
Anyway, Chris writes about the RBC situation
, in which a large Canadian bank had a multi-week snafu with its systems because a developer put in a "relatively small number" of faulty pieces of code into the live systems, causing errors, delayed billings, etc. In addition, hackers took advantage of the situation to conduct large scale "phishing" attempts against the bank's customers.
A mess certainly, and it is understandable that Chris would be interested, and focused on the business control aspect, given his business focus. I even like the analogy he paints of changing your oil at 70MPH. The only problem I have with it is he paints it with too broad a brush.
Business controls are wonderful. There is no way on earth that somebody should change a bank's production code without a heck of a lot more Q&A and process control. But just as I wouldn't dream of changing my oil at 70MPH, I would even less think of pumping gas while driving, but that doesn't mean nobody does.
Yup, this is just one of many airplanes that refuel in mid-flight. Is it safe? Well, relatively so. Would it be safer if they landed? Probably. So, why do they take the extra risk?
Because it gives them a longer range and saves time. Most refueling seems to be faster, fighter jets being refueled by slower cargo planes. It makes sense for the fighter jets to stay aloft, even if there is an increased risk. So, they refuel in mid-flight, and have since the 1940's.
Similarly, some applications should never be modified while running, but there are plenty of others that can, and even should. I have watched companies spend huge amounts of money (not CAN$165M to be sure, at least at one time) on bureaucratic controls that were not necessary, because the same rules of process control were applied to every piece of software. Some of these companies have learned, much to their benefit, that Lotus Notes/Domino can, in certain circumstances, allow for a different set of rules. When the stakes are not so high in case of a problem, but the long term benefits of continual change and improvement are high, it may make sense to change the system in "mid-air", so to speak. Similarly, a system that can be created and deployed at low risk may also be deployed at low cost, but not if it has to meet too many process control restrictions.
So, I guess I don't disagree with Chris as much as I'd like him to draw a clearer line, using a finer paintbrush, as it were.
Copyright © 2004 Genii Software Ltd.