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 🙂 


Comments (4)

  1. damien morton says:

    A long time ago, when I was fresh out of university, I worked for a computer games company. I wrote some data compression/decompression code for them which was pretty cool – the decompresion used only as much memory as the buffer into which the data was decompressed (which was important when you had only 8K of RAM and 128K of ROM), and was competetive with pkzip as well as being very fast.

    10 years after I wrote that code, and quite some time after I left that company, I bumped into someone who was working at the same company. We talked and it turned out he had worked on my compression code. He accused me of being a bad programmer, because he had improved its performance by a factor of 2. I was happy though, because my code was still being used and improved on 10 years later.

    I wouldnt be surprised if the code was still in use, somewhere.

  2. The good news is that there’s not much code at Microsoft that fits that category currently (although there IS some in the MS-DOS emulation logic in Windows).

    Old enough to drive? Yup, there’s that in spades (I work on some of it). But not old enough to drink.

  3. Nick says:

    What’s worse is when you deal with code that’s old enough to drink… and you have to make it work with new code.

    My current client has a very large mainframe system that we are writing software to interact with… using .NET. You know… I wasn’t bald when I started this assignment.