Our project team supports a couple large enterprise applications. We often find ourselves spending time troubleshooting production support issues.  These tasks end up taking a significant portion of time away from development.  We often put in a quick fix that satisfies the one particular condition that is causing the error.  More than we would like to admit, we unknowingly break another feature or another condition of that feature. 

Our team is working on a changing the way we fix these bugs.  Instead of fixing the bugs directly in code and then manually testing them, we are creating a test (either unit test or automated GUI test) that represents the failing condition.  This test is intended to initially fail.  Then it is the developer’s job to fix the broken test.  This is helpful for a couple reasons.  One, by being able to create a test that fails, this is good evidence that the real issue has been identified .  This should eliminate times where we "think" we see the problem and end up not fixing anything.  Secondly, the developer (and entire team if using a CI build notification process like Team Deploy) will know exactly when this is fixed.  Lastly, by adding these as tests, this condition will be tested forever, every time the tests run.  This will ensure that other fixes down the road won't break this condition of the feature. 

In addition to the benefits, this supports Agile and Test Driven Development.  Just like TDD, this starts with a broken test that the developer will fix.  The TDD term is "Red, Green, Refactor".
This isn't always an easy process.  Everyone thinks it is a good idea, but when it comes to doing it, it takes longer and the tests are often hard to create.  However, I believe the long term benefits greatly outweigh the challenges.  Let me know if works for you.

Code Smart Not Had

Mike