Lessons From Your Toughest Software Bugs

Nerval's Lobster writes: Most programmers experience some tough bugs in their careers, but only occasionally do they encounter something truly memorable. In developer David Bolton's new posting, he discusses the bugs that he still remembers years later. One messed up the figures for a day's worth of oil trading by $800 million. ('The code was correct, but the exception happened because a new financial instrument being traded had a zero value for "number of days," and nobody had told us,' he writes.) Another program kept shutting down because a professor working on the project decided to sneak in and do a little DIY coding. While care and testing can sometimes allow you to snuff out serious bugs before they occur, some truly spectacular ones occasionally end up in the release... despite your best efforts.

Comments

Hardly devastating, but a waste of several hours

[Rei]

Program crashing at startup? Okay, let's add debugging statements.

Can't get the debugging statements to execute? Okay, let's try removing code.

Doesn't fix the problem? Okay, let's keep removing more... and more...

A couple hours later, so much code was removed that the entire program had become nothing more than an empty main function that still crashed. This led to the following rule which I try to follow to this day: Make sure that you're actually compiling and executing the same copy of the code that you're modifying. ;)

You are not qualified to debug your own code

[myowntrueself]

I recall a proverb, something like

"It takes twice as much intelligence to debug code as it took to write it.
So if you code to the best of your ability you are, by definition,
not qualified to debug it."

Re:Compiler optimizer bugs

[Jeremi]

I was working at my first job writing my first program ever that was not a homework assignment, I decided to write it as a multi-threaded program

^^^ 2015 nominee for most terrifying sentence on Slashdot :)