Grand Unified Bug Theory

A lot of programmers I know like to follow the Grand Unified Theory of why their software has so many odd behaviors.  They see fifteen problems, and decide it's a single bug.  Or they see sixty, and know that it all arises from a handful of errors. If that sounds ridiculous - well, be sure you don't do it yourself. If it doesn't sound ridiculous, please understand I know where you're coming from.  But DON'T do it! I have had a couple of "unified bug" wins myself.  Some co-workers gave me a Jose Cuervo hat when I had three in one day (years ago!).  It's very ego gratifying and it's tempting to try to do a star turn when confronted with a large group of problems.  And, of course, when you're confronted with a large group of problems, another inviting alternative is... panic! You can lose a ton of time and not make any measurable progress if you keep looking for this.  You have to check all the bugs you think you're fixing.  But you've been saving time, right?  So you actually don't do full testing before committing it and sending it downstream. Congratulations, you have just proven your grand unified bug theory!  You have made a single change that introduced 25 more bugs!  Too bad it only solved two of your existing bugs - you think - and not the one you were sure you'd fixed. Another part of this Grand Unified Bug pathology is that you frequently don't have an actual bug - you are so cool that you are fixing an unreported meta-bug! Don't go here.  Think about what is actually happening if you have a bug that is so systemic that it manifests itself in numerous other bugs.  You have software that is dependent on that bug.  Probably it was considered a feature by the doofus who originally programmed it - especially if it was the doofus in the mirror. And your single simple fix - was it really as simple as you thought?  Lots of times you say it's a simple fix, then to make that "simple" fix work you go around to edit another dozen or two files. If you really have a systemic bug, you cannot expect or trust a quick fix.  You will typically need to refactor.  Refactoring must be thoroughly tested.  It must be analyzed.  If you think you can fix a bunch of bugs with a single stroke - "seven at one blow!" - STOP! Please - analyze single bugs thoroughly.  Solve multiple bugs by choosing a good bug to fix first.  Understand it.  Verify your understanding by reproducing this bug in alternative test cases.