tags:

views:

873

answers:

13

I'm quite a aware of the "subjectiveness" of this question. But I just wonder how you got along with "old" or older code. The oldest code I still have and understand was my theme for my diploma now at least 15 or so years ago. Some other code I've had to maintain and extend is around 12 years old. The first one was written in Eiffel; the latter one in C.

I have tons of small scripts and other programs hanging around, and parts are still in use, even after 10 years. The oldest Rails code is around 3 years old and was updated early on to Rails 2.2.2.

The oldest, general useful code is all of the code running my operating system. In fact I even have OpenGenera (a Zeta Lisp based OS) which still runs.

I'm quite happy that even after all these years I can use this code and even extend it.

So what are your experiences with old code that you've had to maintain and extend?

Please also share what language the code was written in. In my experience, C based code seems to last longest and mature the most gracefully (I may be wrong!).

Ok I was asked if I considered closing the question. But I did not like to do that now, I wished some more would let us know about it. Currentlly may OpenGenera is one of the "oldest" packages besides the FreeBSD stuff. I can not judge about the mentioned mainframe software however.

Ok, then for now it seems the OpenGenera code is base on code which is the oldest the big Lisp time was in the 80ies AFAIKT.

+1  A: 

I have been maintaining code for an embedded real time device written using Visual Basic 6.0 and C++ Builder 6.0. I believe that some of the VB code was ported from VB 4, and I know we use some C math libraries from the mid-90's. Those C libraries are probably the best code (most reliable, easiest code to read, most modular) in the whole system.

Colin
+6  A: 

Well, up until two years ago (don't worry, it's still being developed, I'm just on a different team), we still worked on the development and maintenance of ISPF, the user interface of z/OS (OS/390, MVS). There's still plenty of code in there from the mid-sixties.

In fact, the last of the 24-bit code was finally replaced only about 3 years ago. That won't mean much to you young whippersnappers, but all the mainframers will understand.

paxdiablo
+6  A: 

In 1992 I re-implemented the sed(1) stream editor for the 4.4 BSD Unix system. It's now part of FreeBSD, NetBSD, OpenBSD, and Mac OS X. I'm perform occasional fixes and small changes in its FreeBSD source tree version, and they seem to propagate to the other systems. This is a 16 year old code, that's still running fine and is still usable and useful today. This is the beauty of working on stable-well designed systems; your code ages very slowly.

In contrast, work I did on various Microsoft platforms (for instance, a visual programming framework I implemented on top of Visual Basic) seems to age relatively quickly and become obsolete.

Diomidis Spinellis
Your command line vs GUI application comparison is unfair. Of course your command line application will not age and neither will the visual programming framework application as long as the environment doesn't change. Much won't change in the command line application's environment. My two copper.
Bobby Cannon
I agree with what you're saying regarding the changing environment. But for GUI apps a lot of the environment change is gratuitous.
Diomidis Spinellis
This code was writen in C. So yes I think much of the older code will use C, Fortran, Cobol. I guess some older Cobol systems are quite a long time in use. To GUI code, I just can say out IDE is based on Win32, it still runs and it runs faster than ever before
Friedrich
+2  A: 

The oldest code of my own that I maintain dates back to 1987, but there is very little left from before 1993 that has not been modified (updated, improved) since then. I updated one of the last hold-outs about a month ago - someone else needed to use it; I knew there was a reason I'd kept it for all these years!

Some of the software I work on has roots as far back as about 1982, but again, almost all that code has been modified (I wish I could say it had all been improved) since then.


Friedrich asked: What programs were written?

The oldest material of my own that I still use is called SQLCMD (and pre-dates Microsoft's program of the same name by a long time!), which was derived from a predecessor called RDSQL. Both programs have the same goal; to provide an alternative to the Informix program called dbaccess (or, the original version, which was called isql - I'm glossing over some complications there). The programs allow you to execute SQL statements against Informix databases. The difference is that SQLCMD is designed for use from scripts (meaning originally, primarily, shell scripts) whereas isql and dbaccess had a curses-mode UI and were designed for interactive use rather than batch use. SQLCMD is available as 'Open Source' from the International Informix Users Group (IIUG) web site. It is licenced under GPL v2. It is mainly C code; these days, it has a small Yacc grammar in it too. It uses ESQL/C (because ODBC was not available in 1987) to access the database. Version 86.00 is available at the IIUG; I'm using a pre-release of 86.01. (Yes, it really has been through that many versions!)

I also have a bunch of scripts from 1987. The one I use most frequently is called ow, derived from a script in Kernighan and Pike "UNIX Programming Environment", which runs a filter command (that writes to standard output) and overwrites the original file if the command succeeded. I seldom use that directly; I usually use it via rfmt (for re-format, dating from 1988), which is a wrapper script the runs a reformatter on each of its input files.

One of the uses for rfmt is removing stray blank lines or trailing blanks from a bunch of files prior to check-in into the VCS. Given a program stb to strip trailing blanks (and tabs), and the standard command uniq, and a command rcolist to report checked out files:

$ files=$(rcolist)
$ rfmt stb $files
$ rfmt uniq $files
$

Those scripts are (currently):

:   "@(#)$Id: ow.sh,v 1.6 2005/06/30 18:14:08 jleffler Exp $"
#
#   Overwrite file
#   From: The UNIX Programming Environment by Kernighan and Pike
#   Amended: remove PATH setting; handle file names with blanks.

case $# in
0|1)        echo "Usage: $0 file command [arguments]" 1>&2
    exit 1;;
esac

file="$1"
shift
new=${TMPDIR:-/tmp}/ovrwr.$$.1
old=${TMPDIR:-/tmp}/ovrwr.$$.2

trap "rm -f '$new' '$old' ; exit 1" 0 1 2 15

if "$@" >"$new"
then
    cp "$file" "$old"
    trap "" 1 2 15
    cp "$new" "$file"
    rm -f "$new" "$old"
    trap 0
    exit 0
else
    echo "$0: $1 failed - $file unchanged" 1>&2
    rm -f "$new" "$old"
    trap 0
    exit 1
fi



:   "@(#)$Id: rfmt.sh,v 1.5 1997/06/02 21:45:00 johnl Exp $"
#
#   Generic file reformatter

usage(){
    echo "Usage: rfmt [-c|e] formatter file [file ...]" >&2
    exit 1
}

# Determine formatter
case "$1" in
-c) ev=;     fmt="$2"; shift 2;;    # Normal mode
-e) ev=eval; fmt="$2"; shift 2;;    # Evaluate formatter argument
-*) usage;;
*)  ev=;     fmt="$1"; shift 1;;    # Compatability mode
esac

# Use formatter on each specified file
case $# in
0)  usage;;
*)
    for file in $*
    do
            [ $# -eq 1 ] || echo $file
            ow $file $ev "$fmt" $file
    done;;
esac

I also have an alternative to make called rmk that I still use. It understood RCS and SCCS the way I wanted it to even back then.

The software I work on that has ancient roots is also Informix related; I occasionally deal with C-ISAM, first released in 1982, and also with 'Informix 3.30', last released in 1986 (yes, I mean that was when the last official releases were made - and I still get questions from customers who need to migrate from it to something newer; the latest such case was in November 2008, after a 3+ year gap). Some of the code in current Informix Dynamic Server (IDS) and Informix 4GL (I4GL) can easily trace its origins back to C-ISAM code - though the VCS system (Atria ClearCase - chosen by Informix long before IBM bought either Rational or Informix) only dates back to 1994.

Jonathan Leffler
May I ask in what is was written? Regards
Friedrich
+3  A: 

The first version of Noweb was distributed (by ftp and CTAN!) in 1989. The last nontrivial bug I remember fixing was an embarrassing bug in lexical analysis caught by code-coverage testing in 1993. I still maintain the code and do tend to accumulate minor bug fixes to the tune of a new release every couple of years. Most of the changes occur to accomodate changes in other software such as LaTeX or GNU Emacs. (Noweb generates LaTeX and includes an Emacs mode.) The underlying system is rock-solid and quite maintainable. That's because it does one simple thing well, just the way Brian Kernighan and Bill Plauger told us it should.

The system does have an unmaintainable corner---it includes its own LaTeX-to-HTML converter. I hope nobody uses it but me :-)

In general my old C code is easier to maintain than old code I have written in any other language. Perhaps in order to have a chance of getting C code right, I am forced to keep things utterly simple? Or perhaps it is because C is the only language I used in 1988 that I still use today...

Norman Ramsey
Let me come back to this, isn't it the case that many of the older codes has been written in C and that C does not have changed that much in the last 30 years or so?
Friedrich
No, C has changed more than Icon, and yet my old Icon code is harder to maintain than my old C code.
Norman Ramsey
+2  A: 

Most of the code I work on was originally authored 7-10 years ago by previous incarnations of my team. Some of the least maintainable portions of the code have since been replaced/rewritten/refactored during the last few years... particularly because I enjoy cleaning up old/dead code when I need a break from my normally scheduled coding activities.

What's most interesting are the algorithms and data structures that were designed during a very different time. For instance, there's one time-sensitive component I maintain that was suffering from some time versus space trade-offs that were going in the wrong direction (e.g. optimizing for low-memory constraints instead of running time). One day I stumbled upon some comments from years ago explaining why those original trade-offs had been made, and was fairly amused to consider what had changed in the intervening time.

Reuben
+1  A: 

My current project dates to 1987. It was written in 8051 assembly that was assembled on a VAX using a HP 64000 assembler. We just got it ported to the keil in windows. I am in the process of converting the build and EPROM scripts off the VAX. I have been using a combination of CYGWIN bash scripts .. Solaris (version 1.5 so I had to deal with the only one group at a time problem)(Our CM is done using RAZOR on Solaris), csh scripts...PERL scripts.. and now, I am finishing it up with using the SREC 1.45 program for conversion and fill to the tektronix format. All the integration testing code is run on a simulator on a Solaris machine terminal and is done using FORTRAN and c. All the code for the simulator is 30 years old. This is being done partly because we could not let our unit testers, who are foreign nationals, access our VAX (ITAR). All of my questions since I joined stackoverflow.com have been related to this endeavor.

Paul
That would be quite old code agreed....
Friedrich
A: 

At work, the product I've been working on was created in the mid 1980s, and there are large, mostly unchanged except for K&R function declaration modifications, blocks of code that date from as far back as 1983.

Edit: Oh yeah, and it embeds a scheme interpreter from that period as well.

Josh Matthews
This is quite old but I think the Lisp machine stuff still is a bit older...
Friedrich
A: 

Just 2002. Thank god.

The Alpha Nerd
Isn't that a pity, you won't be proud of your eldest code?
Friedrich
The code I wrote was 2007. I just compile code from the CodeProject, compile, edit it, then stash it away for another day.
The Alpha Nerd
A: 

I'm currently still managing a site that has PHP (v4) code that dates from '99, guess that's pretty much the oldest. Although I should convince those people to consider a rewrite/major overhaul :-)

I still have code here from software I wrote before that, but those aren't really used anymore so that doesn't count hehe

Blizz
+2  A: 

There's an intern at my place who has to maintain a truly monolithic C (no ++ for you poor intern) library which is still on production servers with version 1.0 dated 1984 - the intern was born in 1989.

Poor sod.

annakata
+1  A: 

In my last job there was a C program that was maintained by the "Dream team" this program had originally been in custom hardware about 30 years ago, slowly as general purpose CPUs got better it was translated to C, now no one who remembers the hardware implementation still works for the company and there are large sections of code we think are never executed but can't verify.

Problem is it's the core product that all their other products are based on, and thier clients are the kind of people who don't like change, because it's used to hold really sensitive data, and it's not broken and doesn't thus doesn't need fixing.

It's apparentlt a bitch to get new features into it, unicode support was on the cards from when I started working there and was still in planning when I left, no one was brave enough to actually do it...

Omar Kooheji
great that add your experiences, please go on
Friedrich
+2  A: 

Nice question. It reminds me of Pham Nuwen in Vernor Vinge's A Fire Upon the Deep wherein Pham is a "Programmer Archaeologist". (See also this question here on Stack Overflow and this definition at Slashdot.)

I wrote a custom order entry system in Delphi for a client back in 1998. As his business continues to evolve so does my 11-year-old code. About every 18 months or so I am asked to make a few modifications or enhancements. It's a kick to dig back into that world of Delphi that I loved so much. (I was a Clipperhead before Delphi, and C# / Javascript now. I miss Delphi.)

Alan
That's was with the point in my question. Which Language has turned out to be stable for more than 6 months or so...
Friedrich