Test what you Ship, Debug what you Test

Debug what you test. When you test, you'll find failures, and you'll need to debug those failures. So you need to be able to debug what you test.

Therefore you're going to need to be able to Debug what you Ship. This also happens when you get crash reports from the field.

So don't delude yourself into thinking that you can have some retail-only feature that doesn't need to be at all debuggable. I hear this a little too often. So:

- build PDBs for public builds, not just internal builds.- be wary of obfuscation techniques that are completely undebuggable. - be wary of applying some post-build optimization magic that can't be debugged.- consider having a few global pointers to key data structures so that you can find them in retail bits. The extra 4 or 8 bytes of data will save you many hours.