"A blame culture is corrosive, eroding the team ethos that is vital for success. If they fear that they will be pilloried or punished for their mistakes, your colleagues will start worrying more about how to protect their back than doing what’s best for the team and wider organization. In the worst cases, this can even lead to lying, setting up fall guys, and other dysfunctional behavior." (Paul Butcher, "Debug It! Find, Repair, and Prevent Bugs in Your Code", 2009)
"Anti-patterns are the dark side of patterns - common mistakes we fall into repeatedly. Sometimes they seem to be good solutions that experience has demonstrated don’t work in practice. On other occasions, we know that they’re not a good idea, but we fall into them anyway." (Paul Butcher, "Debug It! Find, Repair, and Prevent Bugs in Your Code", 2009)
"Before you start trying to reproduce the problem or hypothesizing about its cause, you need to know exactly what is happening. And just as important, you need to know what should happen instead." (Paul Butcher, "Debug It! Find, Repair, and Prevent Bugs in Your Code", 2009)
"But remember that refactoring should never be combined with modifying the functionality of the code, and that very definitely includes fixing bugs." (Paul Butcher, "Debug It! Find, Repair, and Prevent Bugs in Your Code", 2009)
"Diagnosis is the key element of debugging. This is where the rubber meets the road and you arrive at the understanding of the root cause of the behavior you’re seeing." (Paul Butcher, "Debug It! Find, Repair, and Prevent Bugs in Your Code", 2009)
"Every piece of code is built upon a platform of myriad assumptions - things that have to be true for it to behave as expected. More often than not, bugs arise because one or more of these assumptions are violated or turn out to be mistaken." (Paul Butcher, "Debug It! Find, Repair, and Prevent Bugs in Your Code", 2009)
"Everything you do is based upon a foundation of assumptions. You can’t possibly avoid making them, and it’s crazy to try - you can’t work from first principles every time. But assumptions are dangerous, because they create blind spots - things you treat as true without necessarily having direct evidence." (Paul Butcher, "Debug It! Find, Repair, and Prevent Bugs in Your Code", 2009)
"Experiments are a means to an end, not an end in themselves. There is no point performing an experiment unless it proves something." (Paul Butcher, "Debug It! Find, Repair, and Prevent Bugs in Your Code", 2009)
"If you make a single change and see an effect, you can be pretty certain that the one caused the other. If you make more than one change, however, it can be very difficult to be sure which change resulted in which effect. Or the changes may interact in unpredictable ways. At best, this might mean that you are unable to conclude anything useful. At worst, you may reach misleading conclusions that lead you down completely the wrong path." (Paul Butcher, "Debug It! Find, Repair, and Prevent Bugs in Your Code", 2009)
"Most bugs are caused by simple oversights. Yes, occasionally you will be faced by something very subtle, but don’t overlook the simple things." (Paul Butcher, "Debug It! Find, Repair, and Prevent Bugs in Your Code", 2009)
"One final point - whether fixing bugs or implementing new functionality, it’s good practice to always examine exactly what it is that you’re about to check in before every check-in. It won’t take long, and every once in a while, you’ll catch a change that you really didn’t intend to make from slipping through." (Paul Butcher, "Debug It! Find, Repair, and Prevent Bugs in Your Code", 2009)
"Part of the beauty of software is that it’s deterministic - the computer does exactly what you tell it to do, and, given the same starting point, it will do exactly the same thing every time." (Paul Butcher, "Debug It! Find, Repair, and Prevent Bugs in Your Code", 2009)
"Successful reproduction [of bugs] is all about control. If you control all the relevant variables, you will reproduce your problem. The trick, of course, is identifying which variables are relevant to the bug at hand, discovering what you need to set them to, and finding a way to do so." (Paul Butcher, "Debug It! Find, Repair, and Prevent Bugs in Your Code", 2009)
"The best defence is to maintain a record of the experiments you’ve tried and what the results were. This doesn’t have to take a long time or include huge amounts of detail - just enough to ensure that you don’t forget what you’ve already done. Periodically review your notes to refresh your memory and help you identify the most promising next steps." (Paul Butcher, "Debug It! Find, Repair, and Prevent Bugs in Your Code", 2009)
"Writing and (particularly) maintaining software is a continual battle against entropy. Keeping on top of quality is tough, requiring high levels of discipline. This discipline is difficult enough to maintain under the best of circumstances, let alone when faced with concrete evidence that the software is uncared for, such as a long-unfixed bug. As soon as discipline slips, quality can go into a self-reinforcing downward spiral, and you’re in real trouble." (Paul Butcher, "Debug It! Find, Repair, and Prevent Bugs in Your Code", 2009)
"We developers can easily develop blind spots. We necessarily have a different perspective from our users, and that can mean we miss important information that would be obvious to someone who understands things from their point of view. Furthermore, our focus tends to be on working out how to make the software work, not proving that it’s broken." (Paul Butcher, "Debug It! Find, Repair, and Prevent Bugs in Your Code", 2009)
"Refactoring is the process of improving the design of existing code without changing its behavior. [...] Bug fixing often uncovers opportunities for refactoring. The very fact that you’re working with code that contains a bug indicates that there is a chance that it could be clearer or better structured." (Paul Butcher, "Debug It! Find, Repair, and Prevent Bugs in Your Code", 2009)
No comments:
Post a Comment