Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I don't specifically mean date-related issues like 2038, but more generally, bugs that fit the pattern:

  • A generation ago, programmers tended to write code that ass-u-me-d X, which was reasonable at the time.
  • But circumstances have changed, and now X is a common source of problems that need to be fixed.

For example:

  • X = "Memory is too expensive to justify storing all 4 digits of the year. Don't worry about 2000; that's a long way off." (broken by Y2K)
  • X = "Who needs size_t? We can just use unsigned int." (broken by 64-bit systems)
share|improve this question

closed as not constructive by Mark Trapp Nov 28 '11 at 16:12

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

7  
I didn't realize that it said "assumed". :) –  muntoo Mar 29 '11 at 7:11
18  
The spelling comes from an American idiom: "when you assume, you make an ass out of u and me" –  Berin Loritsch Mar 29 '11 at 12:51
2  
I still don't think two-digit years were inspired by memory issues so much as punch card issues. Four digits were not a big user of memory, but pushing a card layout beyond 72 or 80 columns was a very big deal. –  David Thornley Mar 29 '11 at 14:17
show 2 more comments

24 Answers

up vote 86 down vote accepted

IPV4 only networking code. The time hasn't come for most people yet, but the idea of IPV4 only networking will become obsolete.

share|improve this answer
1  
doh, posted at the same time as mine :) –  jwenting Mar 29 '11 at 6:59
6  
@jwenting, not quite the same time, I posted 7 mins earlier. –  dan_waterworth Mar 29 '11 at 7:06
1  
I got a message another answer was posted about a second before I pressed the button to post. Something must be off with the timestamping :) –  jwenting Mar 29 '11 at 7:43
show 1 more comment

IPv4 comes to mind. We're running out of IP addresses (in fact it may already have run out, the last batches have been distributed to regional authorities).

Introduction of the replacement IPv6 is slow as hardware and software manufacturers are catching up.

share|improve this answer
7  
As an aside, the grey market for IP addresses has already sprung up. Microsoft were the first to get into the game, spending $7.5m to buy 666,624 IPv4 addresses from bankrupt Nortel: * theregister.co.uk/2011/03/24/microsoft_ip_spend –  Ciaran Mar 29 '11 at 7:17
2  
Duplicate answer - programmers.stackexchange.com/questions/63131/… –  ChrisF Mar 29 '11 at 11:48
1  
posted at the same time, Chris :) Two minds coming up with the same idea at the same time... –  jwenting Mar 29 '11 at 12:56
show 1 more comment

Not quite the same, but the number 10100401822940525 does not exist in Javascript or ActionScript 3.

Specifically, we found that the number 10100401822940525 appears to simply not exist in these programming environment. You can test this for yourself, simply trace or log the following statements: 10100401822940524 10100401822940525 10100401822940524+1 Number(“10100401822940525″) (10100401822940525).toString()

All of the above statements will output “10100401822940524″, when obviously all but the first one should return “10100401822940525″.

Theres no obvious significance to that value. The binary/hex value isn’t flipping any high level bit, and there are no results for it on google or Wolfram Alpha. Additional testing showed the same result with other numbers in this range.

Mystery solved here:

share|improve this answer
5  
-1, This answer doesn't fulfil the second criteria, a change of circumstance. –  dan_waterworth Mar 29 '11 at 8:19
1  
"I know you asked how to boil an egg, but here's how to make toast!" Nah, I kid, I kid. –  billynomates Mar 29 '11 at 12:11
2  
Mystery? It's described in ECMA262 8.3 and IEEE 754. It's not a strongly typed language, why do you expect the types to act like strong types? –  Incognito Mar 29 '11 at 14:30
show 5 more comments

Many localization issues fit this pattern:

  • a generation ago, programmers assumed all characters can be represented with an 8 bit data type
  • a generation ago, programmers assumed every kind of text should be read left-to-right, top-down
  • a generation ago, programmers assumed the field separator in a CSV file is always the comma character , (No, it really isn't. CSV is the file extension, not the file format specification. My guess is, when CSV was invented, it actually was just comma separated values. As it evolved, nobody wanted to rename it to "tabular data file with locale-dependent column separator, quoted fields for field values containing a separator character and double quotes for quote characters".)
share|improve this answer
12  
+10 if I could. Even today, developers assume these things. –  dan_waterworth Mar 29 '11 at 8:21
11  
Well, the separator in a comma-separated-values file IS the comma character. That kind of follows from the term... :) –  Michael Kjörling Mar 29 '11 at 11:54
23  
@nikie: If the separator is not a comma, then it's not a COMMA-separated values file. Clear as mud? ;-) –  Michael Kjörling Mar 29 '11 at 12:00
11  
@nikie, "Word" is just the name of a rich-text editor; not really the same thing. –  David Murdoch Mar 29 '11 at 12:58
4  
@nikie: The RFC 4180 text/csv format (which is what the Wikipedia examples describe) is not localized; it specifically requires commas. –  dan04 Mar 30 '11 at 0:14
show 11 more comments

I did some research on y2010 about 14 months ago:

printf("200%d", year);

Believe it or not, code like that exists.

share|improve this answer
6  
The clocks in all the big, expensive copying machines here at work had to be reset to 2005, since the machines didn't work after new year 2011. –  Thomas Padron-McCarthy Mar 29 '11 at 12:48
3  
when fixing y2k bugs, often we were told to write code assuming any year before (for example) 20 or 30 was 21xx, any date after 20xx. Most of those only exist in conversion scripts, but some exist in code retrieving actual legacy data. Going to get funny in 2020 to 2030 when that code (if still in use) starts rolling over, as all we did was postpone the problem by a few decades (on customer orders, them wanting the quick and dirty solution that didn't change the database). –  jwenting Mar 29 '11 at 12:59
2  
oops :) Thinking ahead again, trying to solve the y2.1k problem. –  jwenting Mar 30 '11 at 6:23
show 4 more comments

Security.

Storing unhashed passwords, leaving "back doors" in applications, using languages that have buffer overflows. See the OWASP top 10 for the current list of dumb assumptions.

share|improve this answer
10  
-1. This question isn't about dumb assumptions, it is about valid assumptions that were invalidated by changing circumstances. Like the assumption that nobody is going to run a program unmodified for 40 years. –  Jörg W Mittag Mar 29 '11 at 10:49
1  
@Jörg W Mittag: I though the Y2K assumptions were "dumb". And I was there -- in the 70's and 80's -- being asked to write code with 2-digit years. I don't see how you can distinguish between date assumptions and security assumptions calling one dumber than the other. What rule do you use? –  S.Lott Mar 29 '11 at 11:14
1  
What assumptions are being made regarding unhashed passwords? I'd argue that storing unhashed passwords is due to extreme ignorance. –  David Murdoch Mar 29 '11 at 13:02
1  
^ That's reaching quite a bit. –  user13280 Mar 29 '11 at 15:35
1  
@Chevex: Time will tell, won't it? Already people look at poor security assumptions and call them "dumb". Not so long ago, they were just assumptions. –  S.Lott Mar 29 '11 at 15:41
show 2 more comments

Single-byte encoding (ASCII, ISO-8859-x) vs multi-byte encoding (Unicode, UTF-8). That's currently the biggest legacy issue I can think of. There is just so much software that assumes that strings' byte length == character length.

share|improve this answer
show 1 more comment

Validators for domain names making wrong assumptions like:

  • TLD is 2-3 characters long (not true since 2001);
  • domain names and TLDs contain only US-ASCII characters (not true since January 2010);
share|improve this answer
5  
I got found this bug in RedBox kiosks. I can't use .NAME or .ME for an email address. –  Mike Wills Mar 29 '11 at 14:29
show 3 more comments

Something that got me royally badly a few months ago was cookie expiration dates...

Apparently, cookie expiration dates can be set only so far forward into the future (correct me if I'm wrong on this point - not an expert on this myself!). Anyway, a few months ago a really bizarro login problem came up with an app that our team was maintaining. But, this was a side-project, and this login component was really solid, didn't have to be touched in 10 years, so nobody was around who even knew how it worked (never had to touch it for how solid it was).

Anyways - after half a day of digging around and losing my mind I noticed there was a hard-coded date of 31st December 2010 in a validation routine. So basically anyone who was trying to use the system with a newer cookie couldn't log in. Turned out this was hard-coded way back in 2001, because they couldn't set a cookie expiration date beyond 10 years into the future - and the programmer at the time was too lazy to make it a "floating date".

share|improve this answer
1  
So much for "really solid"! :) –  Max Mar 29 '11 at 12:08
4  
I'm not sure if this is a real restriction. "Permanent" cookies often set with end-of-unix-epoch expirations (2038). –  Yahel Mar 29 '11 at 15:08
show 2 more comments

Doing any kind of date arithmetic (addition/subtraction) directly on a UNIX Epoch time integer, for example:

gmt_epoch
1301397219
March 29, 2011 11:13:39 GMT

and you want to figure out the correct time for the east coast of America, EST (-5:00 GMT), so you do something like:

gmt_epoch-(5*60*60)
1301379219
March 29, 2011 06:13:39 EST

which is WRONG, because March 29, 2011 happens to be EDT (-4:00 GMT).

This isn't so much a Y2K caliber bug, as you don't have to wait 10 years to see its affect, but, say you hire a contract programmer who is only working on the project for a month or so, then, BAM! the thing breaks after daylight savings time ends.

share|improve this answer
31  
The mere existence of daylight saving time is the real bug here. –  Greg Hewgill Mar 29 '11 at 18:29
3  
Think of the farmers... won't somebody think of the farmers?! –  Jake McGraw Mar 29 '11 at 19:55
3  
@jakemcgraw: Actually, DST was an urbanite idea. Farmers schedule their lives around the sun, not the clock. –  dan04 Mar 30 '11 at 0:17
1  
@dan04 exactly nobody thinks of the farmers –  Jake McGraw Mar 30 '11 at 10:46
show 4 more comments

Another one not yet touched on are applications (and especially websites) assuming that all addresses are US addresses. In an era where international business is increasingly vital, this is causing trouble. Companies are loosing out on possibly lucrative business because customers find themselves incapable of placing orders.

This is especially critical with postal codes/zip codes and phone numbers. Numerous applications and websites validate these against the US system, incorrectly assuming that's the only system that exists (when in fact a lot of the planet uses different systems, and there are countries without any postal codes). A smaller problem is demanding house numbers in addresses, when there are still locations without them (small villages) and sometimes even street names.

Heard a story last year about someone in a small village in France trying to order a phoneline installed (he was just moving there) and finding it impossible as the computerised system used by the provider wouldn't accept his address which existed only of the name of the house and village (no street name, no house number, no postal code).

share|improve this answer
8  
I'd say this is mostly due to lazyiness or budget since address validation is very complex. When looking for guidelines on the subject you will likely see someone telling you "It depends on what you need to accomplish." And it just so happens that, for U.S. localized applications/businesses, a U.S. address is all that will be needed (well, most of the time). This kinda reminds me of the saying that "with unlimited time and resources every computer program will eventually grow complex enough to send email". –  David Murdoch Mar 29 '11 at 15:40
show 8 more comments

One assumption is that our business won't have to grow to non-US (or non-English-speaking) markets. Internationalization when you've done everything right to begin with is a big project. When most of your strings are hard-coded into the code, it's a much bigger project.

There's also assumptions that people make regarding languages.

You can convert between upper and lower case freely (broken in German, with the beta-like eszet character converting into two uppercase Ss).

You have singular and plural forms (some languages have dual forms in addition).

A non-modifier keypress produces a character (friend of mine got hit by a problem that happened when hitting ESC after typing a consonant to form the first part of a Japanese syllable, as katakana and hiragana are syllable alphabets).

share|improve this answer
add comment

I'm just glad I won't be around for the Y10K apocalypse.

share|improve this answer
add comment

Just because Y2K is over doesn't mean programmers are done writing date and time bugs. There were whole families of bugs that struck near and about year 2000. The date and time bugs that continue to arise keep entertaining me in their creativity.

While it's old and becoming dated, the following enjoyed some popularity on the run up to year 2000 and still has some current information.

http://www.exit109.com/~ghealton/y2k/yrexamples.html

While legacy hardware my eventually die, legacy data formats live on and on.

share|improve this answer
add comment

Timezone support and usage. How many systems have you seen that just have dateStarted or dateCreated without any acknowledgement or notation on which timezone is considered the base? Hopefully it's GMT/UTC but counting on that is risky at best.

share|improve this answer
1  
A PC's BIOS clock is a good example of such a system. –  dan04 Mar 30 '11 at 0:18
add comment

Not using an XML library to write XML.

The level of frustration you get when dealing with malformed XML files can sometimes be too much. print "<data>$value</data>"; will most likely fail.

There are so many XML libraries out there that you are bound to find one easy to use. Seriously - stop reinventing what others have spent a lot of resources on already. You may think you know XML but more things can go wrong than you may expect.

share|improve this answer
6  
I'd rather say XML itself is often a major problem :) Having worked on enough projects where it was used only because "it is modern" (even having it forced on us from board level decisions because of that) where it had no added value whatsoever, I've grown wary enough of XML that I'll not use it unless other options are proven not to work. –  jwenting Mar 30 '11 at 6:20
show 3 more comments

The programmer's assumption that a user's geographical location should automatically define that user's preferred language. IP-to-location technology should not be used for preferred language decisions.... ever. Even Google and Facebook are guilty of this one.

share|improve this answer
1  
Surely as an initial guess it's a good start, so long as it's easy to correct when it gets it wrong. –  ICR Mar 29 '11 at 22:44
1  
@ICR: AFAIK pretty much all browsers will send an Accept-Language HTTP header, which specifies accepted languages. If your client is telling you something, overriding that means you think you know better than the client what he wants to see. –  l0b0 Mar 30 '11 at 9:27
show 1 more comment

Assuming a primary key derived from application data will never need to be changed. The most common example is user id - it's usually impossible to change, even if the user changes their name.

Other examples I have come across - assuming country codes never change, currency codes, city names.

share|improve this answer
add comment

32 bits counter in various networking hardware MIBs. They can wrap pretty fast and yet sometime are used for billing...

share|improve this answer
add comment

Using an integer to store currency in its least form. Say cent's. Tomorrow you might use a new currency, it happened in many European countries.

Storing static Vat-rates for categories etc in webstores. In many countries vat rates are considered to be static, but the idea is not to have them static and once in a while they are changed.

Storing civic numbers in a specific notation and use it as a key (or any other "natural key" stuff); tomorrow you might have million of refugees from china, will their civic number look like yours? (Today this is already the case in Sweden)

Assuming 0 is NULL in databases. Next SQL-standard might start count from 0, who knows? :-)

share|improve this answer
3  
Actually it is a good idea to use integers for currency. Otherwise you will only get in trouble with float approximation. –  Andrea Mar 30 '11 at 11:50
2  
@Andrea I am not suggesting to use floats in my post. Integers are a bad idea as we have the Decimal and Money fields in databases. –  stefan Mar 30 '11 at 18:44
show 1 more comment

Well, it kind of fits this question, I guess.

Basically, unsecured WiFi networks. Apparently the standards organizations somehow thought something along the lines of "Oh, only good guys will use open WiFi networks!", so they decided to never encrypt it in any way. I mean, isn't that the type of thing that the Diffie-Hellman encryption key exchange was made for?

This is a pretty big problem today, with things like Firesheep being used fairly widely.

share|improve this answer
add comment

Serial vs parallel processing. Multi core processors are or will be soon seen as universally ubiquitous, with exception of very product or task specific hardware.

share|improve this answer
add comment

Developers - or DBA's - who assume that everyone's name falls into the familiar (to western eyes) pattern of FirstName and LastName.

  • In many Asian countries, the name of the family traditionally comes first because of a cultural value that places the needs of the family over the needs of the individual. Writing "Bevan Arps" can be considered disrespectful, even rude.

  • In other parts of the world, families don't have names - people are referred to by their (only) name. If there might be confusion, their parents or trade are referenced as well.
    [Aside: This is also the source of many western family names like McGreggor (son of Greggor), Mathieson (son of Mathie), O'Connor (son of Connor), Carpenter, Smith, Butcher and Taylor.]

  • Not everyones name has a long spelling - "N" and "O" are the english spellings of genuine names, but many systems reject the names as too short.

  • Not everyone's surname is short enough to fit into a 50 character field either.

  • Not everyone's name gets capitalised the same way. Some people write their surname "van den ..." others "Van Den ..." and adjusting it is wrong.

share|improve this answer
add comment

In the UK when the VAT rate changed from 17.5% to 15% in December 2008 it was the first change to VAT since 1991 and a lot of programs had the value hard coded into them.

The change also meant that the system had to separate out VAT rates based on date, because it wasn't going to be just as simple as changing a constant value somewhere.

Hopefully they were all ready when it changed back (and then increased)!

share|improve this answer
show 1 more comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.