Unit tests. There's nothing like doing drastic refactoring to the implementation of a class when you trust the unit tests to be solid. It's so much easier. [Jon Shute's Weblog] Yes!! That's the key. [Sam Gentile's Weblog] The thing is, "unit testing" is almost a misnomer for what's going on; an xUnit test is as much about expressing requirements as it is about reflecting the inherent capabilities of the software module. For instance, let's say you had a method string Foo(string input); from a strictly "testing inherent capabilities" standpoint, you'd test this by sending it a null, a string a single character long, super-huge buffer-overflowing strings, etc. But from an xUnit standpoint, your first test might be testing that if sent "cow" it returns "woc" and your second might be that if you send it "Cow" it returns "woc" So, in this case, the xUnit tests are expressing, concretely, that the Foo method means "return the string reversed and converted to lowercase." When you have tons of such things and "you trust them to be solid" what you're saying is not so much "This dramatic refactoring does not change the inherent capabilities of the 500 software modules comprising it" as "This dramatic refactoring does not change the value delivered to the client." And that is a very good feeling to have. (Earlier this year, I refactored a template method and it affected every single response the system produced. I did it and integrated it in a single long day. I would have been absolutely paralyzed by doubt had I not had a solid xUnit suite.)