What is the biggest coding error/mistake ever...

Question

I have done a few silly things in my time as a developer and have therefore learnt the hard way in some respects. Here are a few examples:

• Missing out the WHERE clause in a DELETE tableName sql statement.
• No error handling in an application that was using files & db connections.
• Releasing an application without testing (at least the basics).

I'm hoping I don't get caught out again in the future with anything else, so would like to know what other coding errors/mistakes like these other people have done.

Thanks.

Answer 1

The classic one is the single equals rather than the double -

// Last bug in the world
if(code = red)
{
    LaunchMissiles();
}

This particular typo can be very difficult to accurately track down, and in the past I've spent far more time than I'd like going through a debugger and wondering why my if statement was always evaluating as true.

Answer 2

I think mistakes with loops are quite common

• forget to increment counter in a while loop
• a really nasty semicolon after for statement, and before the code block {} (probably not as common now, when we have reasonable IDE's)

Answer 3

Nothing like losing a $125,000,000 ship because someone used English instead of Metric units to which it was designed...

Metric mishap caused loss of NASA orbiter

Answer 4

I did something similar to your DELETE without the WHERE, except in my case it was an UPDATE without the WHERE, and changed everybody's password on the system.

I also managed to not put in any error handling/rollback functionality in an application that modified the httpd.conf file on a server for a web hosting company. Which resulted in about 250 VirtualHost entries being lost. This was in a fairly primitive environment about 10 years ago and there was no easy way to recreate them in batches, so I ended up having to manually input them all.

Both of those really sucked.

Answer 5

String line = reader.readLine();

while (line != null)
{
    System.out.println(line);
}

I do this pretty much EVERY time.

Answer 6

Paul Fenwick has a very entertaining talk on the "An Illustrated History of Failure" and the spectacular failures related to poor software and hardware design. You'll hear about blowing up rockets and bringing down power grids, among other things.

Answer 7

Luckily few of us write mission-critical software that peoples' lives depend on.

This page shows some of the most deadly bugs ever missed by QA: http://www.baselinemag.com/c/a/Projects-Processes/Eight-Fatal-SoftwareRelated-Accidents/

The worst on this list is 225 people that died because a radar that could have prevented a Korean jet crash was hobbled by a software problem.

Answer 8

This one wasn't a programming error per se, but it'll do.

At a previous job, we had just received an oldish computer and were going to format it and reinstall Fedora on it. I had very little experience with Linux, but was under the watchful eye of our resident linux guru. We spent a couple of hours formatting it, reinstalling the OS, installing all the tools we needed etc. The way the workspaces were set up, there was a common codebase that was symlinked into the web directory. We set up the symlinks but there was a problem because the apache user didn't have the necessary permissions to read the files.

"No worries", we thought, we'll just change them all to be owned by the apache user.

chown -Rf apache ./*

(it's been a little while since I've done such a command, so please edit it if I got it wrong)

We hit enter and sat there looking at the blank screen for a few moments. Then I said "this seems to be taking a while...", and that's when we realised it was recursively changing the owner of all files both ABOVE and BELOW this one (following the ../ directories), to be owned by apache. CRAP! ^C!!! Ok ok, what do we do now??? Um um, I know!

chown -Rf root ./*

As that command was running, I said "Isn't that going to stuff up thing even more?". So we thought we'd close our eyes and hope it never happened and restart the computer. Of course, it was too late: even the process which brings up the "shutdown" dialog didn't have access to read the files it needed.

The only thing we could do was reformat and begin again.

Answer 9

I remember in school, for the 1st lab exam we had, I had to write a BASIC program to add 10 numbers. At that time i forgot to put the NEXT statement in the FOR loop and hence my program was going in an infinte loop. Anywayz i still remember this because that's the only time i failed in any lab exam.

Answer 10

Missing out the WHERE clause in a DELETE tableName sql statement.

One habit I was shown is to type out BEGIN TRANS to execute before a DELETE/UPDATE statement, but only type out COMMIT TRANS after I was happy with my action.

Answer 11

Further to nickf's comment about chown -Rf root

On two occasions colleagues have written Makefiles with rm -rf $SOMEDIR/* in the "make clean" section but didn't ensure that the $SOMEDIR was actually set.

On one occasion the guy not only deleted most of the contents of his own hard drive but he also had the company's network drives mounted - the servers were MSDOS based - and managed to wipe out most of their contents as well.

The other guy managed even better - not only did he wipe out his own machine but he'd forgotten that the script was also in the new SDKs issued to our customers and partners. Needless to say we had some very angry ex-customers after that.

I have damaged hearing because somebody "cleaned up" some code - including turning an unsigned into an int. The left shift that was supposed to attenuate the output volume ended up increasing it. Two speakers went up in smoke and I was left with bleeding ears.

Answer 12

I'd nominate this horrible, horrible mistake..

..but ofcourse they could always plead virus

Answer 13

I had a tool which would copy an application to a new website and replace various pieces of data with configured values. For some reason I had an lcase() wrapped in there which lower cased ALL of the Javascript throughout the site. I spent the weekend correcting that mistake.

Answer 14

I once wrote a system to manage an investment fund worth about half a billion dollars. I made a calculation error involving brackets in the wrong place that made the fund depreciate by about 1% every day. That's only 5 million dollars going missing per day... :)

Fortunately the bug was detected after only a few days and I spent one very long night in a cold sweat doing all the recalculations and fixing the data.

Now, if I'd managed to funnel off that 5 millions dollars into my Swiss bank account, I'd have lots more time to answer SO questions... :)

Answer 15

One very nasty little ambush lies in wait in MS SQL Server 2000, not sure about later versions. I was doing everything by the book, designing a new table on the dev SQL server. The new table had a foreign key to an existing table, which happened to be called "Account". Yes, that's the account table for all our clients on the system.

So, after testing and finding that the structure was all good, I created a little DTS job to copy the table structure from Dev to Live. I hit go... and the process seemed to be taking a little too long. So I hit stop... and then... "OMG."

"What?" said all my colleagues, hearing the danger in my voice.

"I've just dropped the Account table."

See, DTS has one sneaky little ambush option called "Update Related Tables" (or something like that), which is set to True by default. And what it does is it drops all the related tables to your new table, and re-creates them. It doesn't even warn you that you're about to drop a table in the target DB; it just says, "OK, boss" and does its thing.

I won't tell you how many man hours we lost trying to recover from that little episode. And I can't even say it was real negligence - that was really nasty of Microsoft to leave that option in there without any warnings... :(

So when you are copying tables using DTS - BEWARE!!

Answer 16

if(underAttack);
    releaseMissiles();

That didn't go very well...

Answer 17

To forget to comment out a fold mark in your zshrc file such that it makes your system useless:

lorem ipsun### {{{
--- 10,000 lines code ---
lorem ipsun
}}}                                # error here
lorem ipsun 
lorem ipsun
lorem ipsun

The mistake caused me a lot of trouble, since it take me take to locate the source of error.

Answer 18

Fence post errors in C. Something like this (although usually not so obvious):

int array[1000];
array[1000]=5;

Answer 19

I caused the tickers of several TV stations to empty out at new years several years ago, by not noticing the difference between the month field of crontab style time specifications and the tm_mon field of the C tm time structure.

Deep inside the server side of our ticker product I had implemented the following function incorrectly:

/**
    This function returns a time_t which
    match the pattern given based on the time. 
    It searches forward in time until a match 
    is found. It calls matching_time with 
    upward flag set to true this is the function
    that does the matching. 

    @param pattern pattern to match
    @param timet base time used with match. 
    @see matching_time
*/
std::time_t next_matching_time(std::string pattern, std::time_t timet);

It turns out the tm_mon field specifies months using integers 0‒11, with January = 0, while the month field in a crontab pattern goes from 1‒12. I got the conversion between these right, but wrapped both mistakingly using mod 12.

The end result: As January rolled in, none of the time patterns used for specifying when to show each message started incorrectly failing to match the current time, thus emptying the ticker completely.

With big names such as CNN using this particular product on-air 24 hours a day, this wasn't exactly my proudest moment.

Answer 20

I sometimes use "find . -name foo.txt | xargs rm" to recursively remove some file that occurs several times in a folder hierarchy. Once I forgot the "-name foo.txt" part which of course meant that I started to remove the whole structure. Luckily I had done a checkin recently.

Answer 21

I (fairly frequently) do this:

SQLDataReader myReader = DataAccessClass.GenerateReader();
if(myReader!=null)
{
    //Do stuff
}

Forgetting myReader.Read() is the bane of my existence.

(Before I'm jumped on, sometimes for simplicities sake a while(myReader.Read) is unnecessary, like when you're only pulling 1 row of data.)

Answer 22

The following is not really an error or mistake, but widespread bad practice.

try {
    // Do stuff.
} catch (Exception) {
    // Ignoring *every* exception, returning an
    // error string or logging it away.
}

I have done this myself and learned over the years, that exceptions should not be ignored but handled properly or rethrown, even at the risk of crashing your application.

Nothing is worse than silent failures in your program. The original error is much harder to find if covered up by swallowing exceptions.

Answer 23

Typical one for me involves logging (examples in Java):

if (logger.isDebugEnabled)
{
    logger.debug("some log message");
    someImportantPieceOfCode();
}

or the similar, except forgot to put braces around something important:

if (somethingBadHappened)
    logger.warn("Can't do any more here; bailing out");
    return;

Don't know why this happens to me so much. I must just zone out in my head listening to Ren and Stimpy's Log Song whenever this happens.

Answer 24

semicolon after if statement

if(condition);
<do something>;

Answer 25

if ( a = b ) ...