Old Code Rusts

Some quotes from the very interesting article "Things You Should Never Do, Part I" by Joel Spolsky (http://www.joelonsoftware.com/articles/fog0000000069.html):

: "The idea that new code is better than old is patently absurd.
: Old code has been used. It has been tested. Lots of bugs have
: been found, and they've been fixed. There's nothing wrong with
: it. It doesn't acquire bugs just by sitting around on your
: hard drive. Au contraire, baby! Is software supposed to be
: like an old Dodge Dart, that rusts just sitting in the garage?
: Is software like a teddy bear that's kind of gross if it's not
: made out of all new material?"
: "Before Borland's new spreadsheet for Windows shipped,
: Philippe Kahn, the colorful founder of Borland, was quoted a
: lot in the press bragging about how Quattro Pro would be much
: better than Microsoft Excel, because it was written from
: scratch. All new source code! As if source code rusted."

Unfortunately, old source code does rust. Of course, source code doesn't change by itself in the way that a car can rust "by itself", but the environment in which the code is used is always changing.

Given the above explanation, the metaphor of 'rust' is even more appropriate. Rust implies that the original hasn't changed--it's just been recombined (oxidized) in a way that makes the whole less functional. A thought experiment: take a block of iron in a sealed environment and measure the number of atoms in the block. Let the iron rust, and count the atoms of iron again. They're still there, but in a less-useful and less aesthetically-pleasing form. Similarly, rusted code doesn't change--it's what the code touches that changes.

Rusty code stories:

I can no longer use a TurboPascal program I wrote some years ago in a 486 DOS/Windows 3.1 environment. In this program I was using a certain video mode and making assembly calls to set and unset this video mode. Needless to say, this program no longer works on my Windows98 Pentium. My program didn't change a bit, but it definitely "rusted"! -- AnonymousDonor
A popular C compiler used to pay attention to the first N characters of an identifier (such as a variable or procedure name) but keep the full identifier in the source code. Various modules were developed, debugged, and archived in source code control systems. Time passes, and the compiler changes to pay attention to the full identifier. Seldomly-changed modules hang around, working fine, for years. Then a disconnected code change (often in the context of make) forces a recompile of one of those modules. BANG. No go. Turns out there's a spelling error in the portion of the identifier that was ignored the last time the code was compiled. No change to source code, no change to dependencies (at least the kind tracked by make or CVS), and code no workie. Definitely "rusted".
CORBA server is written that provides intranet access (both load and store) to resources kept in server-side file system. Clients of the SERVER use scripts that find and archive resources and then mine information from them. Everything works well, including unit tests (on the client side) of the scripts. IS team moves server from Win to Unix environment, adjusting all the drivers and so on. API testing works just fine, except the IS team forgets that Unix filenames are case-sensitive while Win filenames are not. Scripts stop working, though nobody touched them. Code rust.

Examples of things that can make code rust:

changing operating systems
changing hardware
changing user interface expectations

CodeLearns. It is easy to underestimate how much code has learned when the knowledge is encrypted in poor abstractions. If you throw away the code you are going to have to repeat the learning, which could be easier (better technology) or harder (more unforgiving users). One can refactor knowledge to the surface of code. This is much like repeating the learning except that you are never set back to zero. Joel is on to something even if he can't explain it. -- WardCunningham

In other words, old code rusts but is usually easier to fix than replace. -- AnonymousDonor

The longer old code sits, the harder it can be to distinguish between what the code has "learnt" and what it has picked up by way of some prior author's superstitions, or workarounds to long-gone problems. -- DaveSmith

Interesting observation. This means that as we program we are communicating with humans, not just a compiler. We need to make sure that the lessons the code has "learned" are self-evident to MaintenanceProgrammers and not obfuscated. -- AnonymousDonor

One of the dynamics involved is since computers are such a nascent medium, the things we demand out of them are constantly changing. Ask yourself how many functions you ask of your computer that you did not ask ten years ago. Then ask yourself how many functions you ask of your kitchen table that you did not ask ten years ago. Kitchen tables can be made to last 100 years. Perhaps in 100 years, we'll be able to say the same of software.

Code can last 100 years or longer, if you put in in the right place. Software placed in an environment for which it was not intended can not be expected to run any more than a kitchen table lasting when it is placed outside where it is exposed to sun, rain and weather. Programs compiled for one environment can not be expected to work in another.

Who places a kitchen table outside? Aren't kitchens inside, by definition?

Is a kitchen table placed in one's garden or on a balcony not a kitchen table anymore?

No, it's a kitchen table that's being misused, and you can't expect it to last long. You could also chop salad with a lawnmower, and it would still be a lawnmower. It wouldn't be in very good shape, though.

And the salad wouldn't be very good.

Perhaps a more apt metaphor (instead of code rusting) is the idea that one builds a machine that burns a certain fuel and, while the machine itself is indestructible, the fuel supply is eventually depleted, requiring those parts of the machine that process the fuel be redesigned so it will run. It's not perfect, but I think it's closer. -- GarryHamilton

It's not the code or the fuel that is rusting. It's the brackets -- the connections from the code to the larger machine. Changes to these connections in new hardware, OSs, and so on, mean that the old code, which can be as clean as a whistle, just doesn't fit. A huge example of this problem is file formats. Many graphics and data formats from the 80's are not supported anymore. -- IanRae (See AdapterPattern.)

There's an idea in zen that I think makes more sense:

"You never step in the same river twice."

Greek philosopher Heraclitus, actually, although zen in flavor.

Sounds like Heraclitus never crossed a river

Both the river and you are constantly changing. The Turbo Pascal example above doesn't show the Turbo Pascal program rusting; it shows the environment is changing.

Sometimes it's better to fix, sometimes it's better to rewrite. Spolsky is right in that programmers often want to rewrite because it's easier to write than read. He is wrong in assuming rewriting is never appropriate. Of course, when you are at Microsoft with millions of users in multiple languages, rewriting would be very costly because you would need to maintain forward all the learning generated from the user feedback, that's already embedded in the code. On the other hand, a good small team could rewrite, say, Spolsky's FogBugz? in a few months, and only add, not subtract from the value. In that case, most of the value of the software lies not in the embedded knowledge (yet), but in its marketability via Spolsky's popular website.

In the case of prototypes, there is no embedded knowledge, plus a chance the original author cut corners knowing it was a prototype. The value of a rewrite can be quite high in that case.

For typical software, partial rewrites are often better than complete rewrites. Most software has some value.

But absolute viewpoints like "never rewrite" are as suspect as "I can't figure out what this code does, let us rewrite it".

Another type of decay can appear in LegacyCode that has been maintained but not refactored. This isn't usually rust, but an instance of the PlayDohPrinciple.

Another major cause is what might be called "KeyholeMaintenance" - when working with a legacy system, maintainers often only understand a tiny part of the system, so they fix that part, and pray that they haven't broken any of the parts they don't understand. The cumulative effect of several generations of people doing this can be pretty damaging! --PaulMorrison