Wednesday, June 8, 2011

How to Make and Kill Your Own Bugs

The following is a guest post of sorts, written by my boss and given to me with full permission to spread his gospel far and wide.   Though the concerns of his writings involve matters far beyond my technologically-deficient mind, I still found this to be wildly hilarious and hopefully, you will too.  Enjoy.

I have received several requests asking me what it is like to write software.  Let this serve as a guide.

Step #1: Unless you are writing a really small program of less than 50 lines, writing software is actually the creation of hundreds, thousands, or even tens of thousands of bugs.  The intent of course is to produce code that will accomplish something useful.  Instead, the code you have will only be useful for generating error messages, giving out inaccurate answers, or dying with no explanation.

Step #2: Now that you have an unknown, but very large, collection of bugs, you need to start squishing them, thereby creating more bugs.  In software, any change in one part of the program can, and often will, affect other parts of the program that are totally unrelated in function.  If you are fortunate, the number of bugs you squish will be larger than the number you create.  I find that a good ratio is 1.2 bugs created for every 2 squished.  With this ratio, and given enough time, it would seem that all of the bugs would eventually be killed off.  However, given that the universe is 13 billion years old, there has still not yet been enough time to fully debug any known, reasonably large, software.

Step #3: Once you have killed off the majority of bugs, and the program now functions somewhat correctly, and will also serve a useful purpose (mostly), it is time to think of adding new features.  This new code will of course consist of a series of bugs.  In addition, the new code will conflict with the current code which will cause the creation of new bugs in that old code.  Now you will have to repeat step #2 on not only the new code, but the old code as well.  Remember, of course, that the old code was never fully debugged before you added the new features.  A common ratio or new features is that for every bug in the new code, 0.3 bugs will be created in the old code.

Step #4: Once again you have gotten the program to be mostly functional.  Now it is time for users to begin processing data, data that you never intended the program to handle.  For example, the program needs to track a number of persons and you never thought that the number of people being tracked would have a negative value.  Or that the classroom size would be over 10,000 students per class.  Or that a loaf of bread in Zimbabwe would cost over 100,000,000.00 ZD.  Or that the name field would have to be over 75 characters in length and would need to allow for numbers.  Or that a company selling screws would find some way to sell fractions of a screw (55.214 screws).  Or that 5,000 cells with no data in them need to be sorted.  Of course, correcting bugs makes bugs.  Go back to step #2.

Step #5: There have been no reported bugs in the program for a while and you think that you're home free.  This is when the "combo" bugs begin to show up.  In step #4, you had single weird data sets to deal with and you dealt with them.  Now, the problems being reported only occur (for example) if the number of units is an odd number AND the zip code begins with a digit larger than 7 AND no phone number has been entered AND the color choice chosen is paisley AND it is the 31st day of the month AND the data is being saved to a USB data stick.  But you do not know all that because the bug report consists only of the statement "I pressed [5] and the program died with the error message 'Out of string space error in line 255 of module POS4'" which is actually 96 lines before the actual point where the program died because none of the lines between 255 and the problem line are numbered.  And nothing you do to try to reproduce the error will do so because there are 425 color choices and you would never, ever pick "Paisley" for anything.  Good luck finding this bug during your lifetime.  But eventually you will, which then creates more bugs.  Go back to step #2.

Step #6: No bugs have been reported for years so Microsoft tweeks the next version of Windows so that your software will no longer run at all.  Find a workaround that only requires changes to 2% of your code, create more bugs, and then return to step #2.

Step #7: Serial printers.

During this whole process, it would be a swell idea to learn at least one programming language with which to write all your bugs in, but that's the easy part.

- Dale Harris