5typos.net
Debugging as a Project Stage
In a typical meeting where the team has neglected QA and is flying head-first into a release wall, I would throw the cliche at them:
Measure twice and cut once.
Far from being true, this is a last ditch attempt to soften the (crash)landing. In reality — if involved earlier — I would have found a way to transmit the opposite:
Guesstimate quickly, then measure and cut multiple times.
Rarest is the case when there’s enough information on a new project or implementation where you can accurately estimate what you don’t know. There’s all sorts of tricks in which you multiply what you expect based on other experiences.
For best results I’ve found that you must incorporate debug time after the design as part of the overall process. In the majority of cases, the debug part will take considerably longer — regardless of how long to design takes.
Thinking your design is proven because of the time it took, will take you down a dark path. Design and debugging are independent. If you do have a hard date, take time off the design and give it to debugging. It will not be pretty, but it will deliver.