In a recent effort to unit test a body of code that we are developing further, I was quoted Steven McConnells book " Rapid Application Development, taming the wild software development schedule". The gist of the quote was that touching code, no matter how wonderful it makes future efforts, brings risk to a project lifecycle that did not schedule it.
Steven McConnell is right to say changing code is risky. It's like walking a long balance beam. To be sure to stay on the beam progress has to be slow, and meticulous. If you make a mistake you get feedback in the form of the floor making its presents felt. The longer the time between creating the error and getting the feedback, the more it hurts. The solution is to reduce the time between creating the error and gaining the feedback. Lower the beam so it is only an inch from the floor. Once you have done this, there is far less risk, and you no longer have to make slow progress. Suddenly you are free to run along the beam, knowing if you fall, you can always get back on again. You gain confidence and courage.
In development the feedback is in the form of testing. The shorter the time is between writing the bug and detecting it, the less it costs to fix.
Acceptance testing your applicaion, and having a good QA team are great. However the bar is still a meter or two from the floor. By putting in place a suite of fully automated unit tests, and running them after every code change, you are able to catch unwanted changes to functionality as soon as they are made. As a result you are able to develop at a much faster rate, and make large changes to the code-base with minimal risk.