How Not to Read New Code

There is a great article on how to read new code, written by Tim Ottinger. Having maintaining my ex-colleagues code for sometime, I believe that I do have something to contribute here.

I assume that you are dealing with code that

1. Have no unit tests
2. Exhibit strong code smells
   
3. Are deprived of its owners, meaning that the ones who wrote the code is no longer available for consultation

Here are the don'ts:

1. Don't believe in comments. Comments, be it XML comments or any other forms of documentation, are vague at best and misleading at worst. They are often outdated or simply false. In any case you are better off with reading the code because the only comments that count are code.
   
2. Don't assume that every piece of code is intelligent or meaningful. No matter how smart a programmer is, he is bound to make mistakes. What more to say about someone whose code exhibit strong code smells. If you find a method obfuscated or is simply talking nonsense, you need to refactor it mercilessly in order to get any sense out of it, with or without unit tests.
3. Don't change the code without a strong team of testers. As mentioned above, you need to modify code without unit tests. So you need another safety nets to cover you. A strong team of testers would do the jobs. Make sure that they test every possibilities related to your code changes. Expect your bug tracker to be filled with thousands of bug reports.
4. Don't ring up the original coders for help, if they have left for a long time already. Why? Simply because no one can understand poorly written code, regardless of whether it was written by the authors themselves, or any other people after sometime.