It might seem weak to not have a good alternate solution when criticizing someones attempt at one, but I don't have a ready answer. Well, okay so I'll try and

It might seem weak to not have a good alternate solution when criticizing someones attempt at one, but I don't have a ready answer. Well, okay so I'll try and give you advice anyway :P What kind of program is it? Is it a library, console/gui app? Does it have a variable workload? What are the ways in which people interact with the code? Is it primarily a desktop or server side application? What kind of test framework do you have in place? Do you have any instrumentation that would allow you to generate code coverage numbers? Can you run fault injection/fuzzing/etc type testing on it? Is the program resource limited? If so, do you have a CPU/Mem budget that you regularly check against? How many libraries does your program interact with? Do you keep track and test those libraries for failures? Do you try to freeze third party library/SDKs to minimize external bugs harming your own software's reliability? Do you always hard-crash at every bug or do you need to keep the software limping along till shit really hits the fan? Do you regularly (when there is no bug to track) run your software under a debugger to get a good feel for what the call stack, arguments, etc look like in a practical scenario (so that you can train yourself to catch it when things seem out of place). Its a lot about asking yourself what your blind spots are. Sometimes you have to think super-practically and just "look at the bits" and sometimes you have to try to see the forest. It all depends on what you're doing. And sure experience is a mean teacher. Nothing like getting a call at midnight and someone asking you why your embedded code running on-site in another state isn't working right after 5 months of no issues :P