Based on my own subjective experience I've found the numbers regarding testing to be suspicious simply because "bugs" are so varied that any specific number wou

Based on my own subjective experience I've found the numbers regarding testing to be suspicious simply because "bugs" are so varied that any specific number would be subjective. I'd always assumed that these numbers referred to an architectural type of bug where, once made, more code is built upon the bug and so a cascading effect occurs. The more code that relies on the bug, the worse it is to fix because you have to fix all of it's dependent code. In some cases you may need to repair data, or entirely refactor sections of an application. But there's other bugs that are more "typo" level bugs where obviously the time to fix is exactly the same no matter what phase of development. I had just always assumed those numbers were a worse-case average to encourage developers to better plan their architecture. In part because the context of code complete is more about planning and estimation. Though there may not be support for the exact figures, I think the point of them is to not let things pile up and to try to put thought into your design especially at the architectural levels.