- Item 9: Set Yourself Up for Debugging Success
- Item 10: Enable the Efficient Reproduction of the Problem
- Item 11: Minimize the Turnaround Time from Your Changes to Their Result
- Item 12: Automate Complex Testing Scenarios
- Item 14: Consider Updating Your Software
- Item 15: Consult Third-Party Source Code for Insights on Its Use
- Item 16: Use Specialized Monitoring and Test Equipment
- Item 17: Increase the Prominence of a Failure's Effects
- Item 18: Enable the Debugging of Unwieldy Systems from Your Desk
- Item 19: Automate Debugging Tasks
- Item 20: Houseclean Before and After Debugging
- Item 21: Fix All Instances of a Problem Class
Item 14: Consider Updating Your Software
Guess what? Your code is not the only one that has errors in it. The compiler or interpreter that’s processing your code, the libraries you use, the database and application servers you depend on, and the operating systems that are hosting everything all have their own fair share of bugs. For example, at the time of this writing, the Linux source code contained more than 2,700 comments marked with XXX, which typically denotes a questionable construct; some of these are surely bugs.
Consequently, some bugs can be addressed by updating your software. Using a newer compiler or library may help you correct an obscure bug in the packaged software you’re shipping. If you’re delivering a software-based service, then updating middleware, databases, and the operating system can also help. At the very least try building, linking, or running your code with the newest versions to eliminate the possibility that you’re witnessing a third-party bug. However, keep in mind that there’s a lot to be said for a conservative upgrade policy—working with the devil you know. A lot of middleware suffers from faulty or limited backward compatibility, so experienced users are usually very careful when doing updates, opting for the next earliest bug-fixing release (e.g., 6.4.3) that would solve their problem. Also, new software can introduce new bugs and incompatibilities, so at the very least don’t burn your bridges rushing into it: have a sensible back-off plan if the upgrade doesn’t work, or if it doesn’t address the bug you’re witnessing. Updating the third-party code in a sandbox, such as a throw-away cloned virtual machine image, is a reliable and easy way to achieve this. Whatever happens, don’t expect too much from software upgrades.
It’s best to assume that outside code is innocent until proven guilty. Most of the time, bugs you blame on third-party code are actually problems in your own. Over the course of thirty years, I’ve fixed thousands of bugs in my own code. Over the same period, I’ve encountered a single case where a widely used commercial compiler generated incorrect code, a few instances of bugs in libraries, one case of unreliable operating system functionality, a handful of errors in system call documentation, and just tens of errors in tools and other system software. Therefore, the biggest benefit you’ll get from using updated software is a new resolve to get your own house in order.
Things to Remember
Try your failing system on an updated environment.
Don’t expect too much from this exercise.
Consider the possibility of third-party bugs.