Possible Duplicate:
How do you manage to write high quality code very quickly?
When emergency code fixes are required ASAP, how do you ensure that the code you're writing is better than the code you replaced? What processes do you keep when time is of the essence?
It depends on what you mean by better. You can write unit tests to cover the code you are fixing to make sure the code is working. Then you can rollout and refactor later.
If better means its cleaner, well factored. Well that's subjective. If better means faster you should set up an unit test to verify that.
I guess the process that you should keep above all is testing.
What processes do you keep when time is of the essence?
Testing: new code should pass all the same (automated, regression) tests as previous code, plus the new tests which you've written to test the new feature/bug fix.
The simple answer is that you don't write quality code under duress so you must do everything you can to avoid or mitigate the situation.
If anything these are the times when you need to adhere even more strictly to good development practice. What's worse, leaving an application with an error for a few more hours/days (or perhaps taking a site off line if necessary) or replacing one problem with another which may only manifest itself days or even weeks later?
The management need to see that a rush job will only store up problems for the future - explaining this in terms of the revenue lost would be a good place to start - so that they give you the time and space to not be under duress.
At the very least you need to subject any emergency fix to a full suite of regression tests and perform rigorous QA on it after the patch has gone live and be prepared to re-patch if the fix is found to be wanting.
Unit tests. Unit tests ensure that one change in functionality doesn't impact other areas. Other than that I have to agree with ChrisF, rush jobs are never good.
This depends on the circumstances. Rush jobs are never good. But the expense of down-time may be so large that they are necessary. I have worked on process control applications where you sometimes have to put fixes in with a bare minimum of testing because the expense of having the plant idle is enormous; this might also apply to very big websites. I was rather nervous about this, but it generally worked, or the resulting system was good enough to be going on with. Full testing could wait until the plant was back on again.
So the answer is; none. All the 'procedure' could wait until after the fix is applied.
Short answer: you don't. But you can mitigate some of the issues.
Even for my own, open-source code, I have a PC sitting here that does nothing but integration testing (unit testing is fine, but is not the panacea many think it is; it's quite possible to say both "all my tests pass!" and "my program doesn't work!"). For web stuff it's got Selenium installed, and exhaustively tests the code to make sure it works sanely. If I have to rush a patch on something, I can at least wait for Selenium to return before pushing it; almost nothing is that time-critical (and if it is, boy did you screw up and it's time to hash out a fast damage-control patch and then go back and do it right). The one caveat is that Selenium and friends (including desktop applications) cannot perform meaningful system testing unless they are on identical hardware to the Real Thing. (For desktop applications, especially consumer-released ones, this kind of system testing is nearly impossible, but given enough money you can build a reasonably broad testing matrix.)
Unit testing is nice and good for fast turnarounds, but I find that you find the really nasty problems in your integration tests.
Couple of suggestions:
I always start by outlining exactly which problems are immediate fixes and which are just updates or improvements. Then, I ignore the updates and do only the fixes to reduce the size of the task. Then, I create a rough outline of the process that needs to happen. Something like: 1. user enters info, 2, form validates, 3. if validation error.... It is not an entire logic flow chart, since there is not enough time. But having ANYTHING laid out in writing REALLY helps me keep on track. Planning is essential... how much planning is subjective. I try to do only as much as the time I have will allow to do the most effective job. I am ALWAYS under deadlines and clients rarely understand that their "simple" changes are rarely simple.
This is on the touchy-feely side, but one thing to mitigate the danger is to take your proposed fix to another (senior) engineer on your team and say "I think this is the right thing for tonight; I see risks A, B, and C; I considered and rejected solutions X and Y." Once implemented and tested, go back to that engineer and have them review the change with you line-by-line.
If your fix is the Right Thing in the situation, those steps will add less than half an hour to the timeline. If your buddy points out the catastrophic lossage that will occur if you do it, the time it takes to work out a better fix is well worth it.