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.


+31  A: 

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

// Last bug in the world
if(code = red)

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.

Nice one - in C# it wont compile with that but some other languages will actually compile and that code is valid, which would cause a right nightmare.
Haha. That's great.
Appropriate warning flags are available to catch this on most modern C compilers.
Peter K.
lol yeah this one has caused me to lose quite a bit of productivity as well
Actually, I don't ask myself 'why does the if always evaluate to true?', just 'Where did I forget to type the damn =?'
Adriano Varoli Piazza
Personally I always write 'if (red == code)...', which will compile everywhere, and fail to compile everywhere if I happen to forget the second '=' =8-)
À trick Joel (Spolsky) mentions in one of his books is to always write this instead of the usual which will be caught by even the oldest compilers: if (5 == i) ...
Reason why unit-testing and mocking are mandatory for weapon systems code.
Hope that value for red is 0...
@HAdesif(launch = true){ LaunchMissiles();}is valid C#! Though it warns you about launch = true being constant...
Static code analyzers will catch this.
+4  A: 

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)
Isn't forgetting to increment a counter one of the classic blunders? Right after Never Start a Land War in Asia?
+43  A: 

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

They are American units; not English ones. We English use metric these days, and used Imperial before that. LOL.
David Arno
Nice example though of a big coding error ;)
David Arno
I did a semester-long report on this disaster. They had the spacecraft en route to Mars while this software was being written. It was never integration-tested either. Sending data and meta-data could've avoided the entire thing. plus, NASA told the engineers they had to prove a problem existed.
Nothing was lost "because someone used English instead of Metric units". It was lost because units, and the transformations between them, were not used correctly. The former might be misunderstood as implying that one particular measurement system is "bad" and caused the error all by itself.
Daniel Daranas
Surely it's imperial units not english or is that what americans call them. I don't know why anyone would every use imperial for any scientific calculations they make things so messy.
The article says "English".. so Im sticking with it. Nevertheless, everyone here knows what it's refering to.
"English Units" is an unclear term as it can refer both to American Customary units and Imperial units. The systems are similar, but not identical; for example, an Imperial pint is larger than an American Customary pint.
Adam Jaskiewicz
Surely thats a problem with the spec, not the code?
Phil Carter
Still cheaper than the missing dot that crashed Mariner1 or the float-short conversion on the Ariane5
Martin Beckett
+1  A: 

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.

String line = reader.readLine();

while (line != null)

I do this pretty much EVERY time.

How could you mess that up?
Just being sloppy I guess? :)
+2  A: 

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.

brian d foy
+6  A: 

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:

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.

Glad to see that the Therac-25 incident made the list. It's the classic example of this kind of thing.
Bob Somers
"Jury holds maker of flight-management system 17% responsible" 17%?
+2  A: 

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.

The correct command would have been: chown -Rf apache .
Since when does * or ./* follow the uplinks (../ directory)?
i can't remember the exact syntax we used, but trust me, it hosed that pc pretty quick.
@Ether, the problem is that chown follows the uplinks...
Thorbjørn Ravn Andersen

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.

+12  A: 

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.

Smart. I also tend to take my delete statement but do a select first to *see* how many records I'm getting back, or at least count the # (depending on situations). That has kept me from over-deleting before.
+1 - I once did a non-conditional update on an important field. Luckily it was a non-production server.
Kyle Rozendo
+10  A: 

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.

I've had the same issue, but with Ant. Delete task is recursive but doesn't ask you if it's ok to start!
At some time, the Hadoop project (Distributed Filesystem and MapReduce) had such a line in their makefile. I deleted half my hard disk because of that.
LOL. You made my day :)
+7  A: 

I'd nominate this horrible, horrible mistake..

..but ofcourse they could always plead virus

I second this nomination !!!
Scott Vercuski
I third that nomination. Good thing we are converting to Outlook this coming May.
Michael Kniskern
I wish I could upvote this 1000 times!

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.

Ian Suttle
+1  A: 

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... :)

+4  A: 

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!!

What? You had no backups of the production database? That was the real "biggest mistake you made", right?
Actually, Marek, we DID have a backup - but the DB was so huge that it took about 2 days to restore, plus we lost all the data since the backup (and we did create quite a lot in that one day). But +1 for a keen observation, none the less... :)
@Shaul, sounds like your backup procedure needs a bit of care and loving.
Thorbjørn Ravn Andersen
+15  A: 

That didn't go very well...

damn case sensitive...
Neil N
Niel, are you sure you didn't miss the error?
I like this one :)
C Bauer
worst thing is, its very difficult to track down as no error given by compiler

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.

Your first problem is 10k lines of code in a single file
Neil N
@Neil N: True! I had to split the code first to external files first to understand its function, and then subsequently find the bug.

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

int array[1000];
+6  A: 

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.

Rolf W. Rasmussen
What is a "ticker"? what does it mean for it to be emptied?
"Ticker" is TV lingo for the continuous text stream typically sliding from right to left at the bottom of the screen on some television channel.News channels typically show the headline stories or breaking news in their ticker, while financial channels typically show stock quotes.The effect of none of the time patterns of the content for the ticker matching, was that after as the new year rolled in, the content currently on screen slid out, and no new content replaced it, leaving the area of the television screen occupied by the ticker completely empty.
Rolf W. Rasmussen
+1  A: 

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.


I (fairly frequently) do this:

SQLDataReader myReader = DataAccessClass.GenerateReader();
    //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.)

C Bauer
+6  A: 

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.

I agree sir. I've had this come up before, but I always put in an alert nowadays.
C Bauer
Agreed. I hate checked exceptions. These days if the compiler whines about an exception that is not being handled I add "throws Throwable" to the method so that all exceptions are thrown to the caller. At some high level I'll have a catch-all exception handler which shows the user an error or logs and continues to the next record. Sometimes of course you need to clean up resources, but then just re-throw after doing that.

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

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

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

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

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.

+19  A: 
Mike Robinson

semicolon after if statement

<do something>;
If a language permits this, it's a syntax flaw.
+1  A: 
if ( a = b ) ...
i cant even count the hours I have searched though code looking for a bug that turned out to be this. my instructor told me to use this in certain scenarios: if(6 == myNum) instead of if(myNum == 6)