TECHNICAL MEMORANDUMTM-26-007
SUMMARY. The longest-lived code I have ever written does not run in a bank or a satellite. It runs in a text-only multiplayer game that has been online since 1992. Three pieces of infrastructure I wrote as a student in 1993-95 are still the live implementation, thirty years later. None of the reasons they survived is "the code was brilliant" - which is what makes them worth a memo.
1. BACKGROUND. In the early nineties, multiplayer meant text for most of us: MUDs - nowadays an MMO, minus the Massive - shared worlds you reached by telnet, run by volunteers on university machines. The volunteer developers were called wizards. I joined the wizard crew of one of these games as a student and drifted from building rooms to building the code under the rooms - the base libraries the whole world is made of.
2. FINDINGS.
2.1 Three artifacts are still in production. A property system from 1993, written with a wizard from a sister game: every object holds its state as named properties with query and change hooks, and essentially everything in the game inherits it. A virtual-room compiler from 1994 that generates landscape on demand instead of storing thousands of room files - still the live implementation. A daemon from 1994/95 that keeps selected objects alive across reboots. The 1993 copyright line is still in the current source.
2.2 Survival reason one: position, not quality. Foundation code that everything inherits is the most expensive code to replace in a system that is never allowed to stop - and a world that has been running for three decades never gets a rewrite window. Simple contracts at the bottom fossilize; cleverness gets replaced.
2.3 Survival reason two: the documentation moved in with the code. The room compiler still ships with its worked example in the game's documentation tree. Wizard generations I have never met learned it from there. Code outlives its author only if the knowledge does.
2.4 Survival reason three: someone always ran the machine. When the game lost its university home in 1999, it moved into the machine room of the research institute where I worked, and for almost eight years I did the migrations, the backups, and the hardware care. In 2007 I handed the server on. The game keeps a family tree of its wizards - who trained whom - and the volunteer who took over descends from my line. It has moved again since. It did not need me anymore, which was the point of the handover.
3. CONCLUSIONS. Longevity is not a property of code. It is a property of the system around the code: boring contracts at the foundation, documentation that can teach the next volunteer, and an unbroken chain of people who treat keeping-it-running as part of the fun rather than as a cost. Nothing on that list requires brilliance, and nothing on that list is optional. Every production system I have built since has depended on the same three things - the game just proves they work without a budget.
4. ACTION. None required, which is the finding. The game is online as I write this, and wizards I have never met maintain code I wrote before some of them were born. That is what a system outliving its builders looks like: unspectacular, documented, and backed up.