Friendly code fixes are corrections or enhancements that developers make for a particular customer, even an internal one, that are outside the normal release process. For example, an emergency fix might be needed if a customer system is down or severely crippled. Or, an emergency enhancement might be needed to close a new contract before the end of the quarter. In either case, the new code passes directly from the developer's desk into production, bypassing configuration management, quality assurance (QA), release management, and product distribution.
If a friendly fix sounds like "friendly fire," that's because it often has the same effect: You end up hurting your own cause.
While it's hard to fault the desire to be responsive in a crisis, the risk of a friendly fix is that it may backfire and leave the customer worse off than before. Friendly code fixes can also completely confuse the customer support team, which has neither seen nor heard of this new code before. Later, if the code isn't included in the next release of the software, the fix may become undone. In any case, what starts out as a good deed turns into a disaster.
So the dilemma is this: How do you remain responsive to your customers without sacrificing the very processes that protect them?
The first thing to do is face the facts: Emergencies will happen.
As much as we all prefer to make all of our plans and processes in an orderly and predictable world, reality always intrudes. Software emergencies are unplanned, unwanted, and usually occur during mission critical situations. No matter how many policies and procedures you have in place to prevent emergency code fixes, and although you swear you will never let one happen again, it will.
While you're staring down reality, you can also face the fact that being able to respond nimbly to a code emergency is a good thing.
In a truly critical situation it's important to have a means of rapid response. Granted, it may not be ideal and it may circumvent steps that are designed to protect everyone from unforeseen consequences, but when you need it, it's good to have an emergency code-fixing strategy.
So how do you plan for a code emergency?
Do No Harm
You've probably heard that if you happen upon someone who has been in an accident you should resist the urge to move them unnecessarily. You may exacerbate injuries. The same is true of a software emergency. Before you inject new software code into any production environment, make absolutely sure that you can recover if it backfires. This means make a backup of everything--software as well as data--so that you can at least retreat and start over.