Code that's old enough to drink

I heard a great expression today when talking with another team here: "Code that's old enough to drink."

In other words, code that's been around for more than 21 years.  Now if that were teens, i'd make some joke about it be temperamental and "trying to be different".  But instead, since it's in its 20s, i'm just going to say that this code is estranged.  It's lost it's way and doesn't know what it's purpose in life is anymore.  When written it had to deal with constraints that i can't even imagine.  Profilers of the day realized that derferencing individual pointers was too expensive and so you just jammed a block of variables into the small amount of memory you had available, partied on that, and then swapped that out for another set of variables.  Assembly was necessary in many cases to provide code that would operate at a speed that was acceptable to users, and woe be to you if you even considered using something as newfangled and crazy as an "ob-ject".

This is code that's older than i am!  Yikes!

I'm sure there are tons of you out there who deal with this on a daily basis.  Cobol code that's decades old.  Mainframes that run code taht hasn't been touched in years (and the last time it was looked at was probably because of the whole y2k hullaballoo).  etc. etc. etc.  It's pretty scary stuff, but it's also amazing to see that some code can really last the test of time and still be usuable after all these years.   Of course, once you hit the first bug in it now you're sure to all rip it out and replace those 10,000 lines of assembly with one line of VB :-)