Categories
Uncategorized

FutureCode

We were working on an application that dealt with dates, and in the database, I asked what we should use for the expiration date, and someone suggested some time in the year 2050…

We were working on an application that dealt with dates, and in the database, I asked what we should use for the expiration date, and someone suggested some time in the year 2050.

I wish I could laugh at that, or think it’s a good idea, but it worries me. I mean, this seems to presume a few things:

  • We won’t be around, so it’ll be someone else’s problem
  • The code won’t be running by then and will have been replaced

The first one bothered me because I don’t really like to leave problems behind for other people to deal with. I mean, that’s what happened last time right? I’m sure the guys writing code in the 1970’s were like “Hey man, this code won’t be around by the year 2000, so just use 2 digits to store the year! Groovy!” or something like that… But I’m here to say that I did fix code that broke in the year 2000, and it wasn’t fun…

The second one bothered me because it’s sad to think that the code we work on today will probablty be useless in a few years. In fact, within 5 years I’m sure people will be complaining about how crappy it is, and keep asing when it can all be moved to a new system. I say that because I’ve seen it happen before, and that’s how we got here in the first place…

You just can’t win, can you? Oh well, I suppose we won’t have to worry about it after 2038

3 replies on “FutureCode”

Comments are closed.