“If it ain't broke, don't replace it. The AS/400 banking systems running today were written by people who are now retired. The software is still correct.”
The Machine
The IBM AS/400 was introduced June 21, 1988. It was designed as a midrange business computer — between mainframes and personal computers — with a clean-sheet architecture that made several unusual engineering commitments:
Technology Independent Machine Interface (TIMI): programs compiled for the AS/400 compiled to an intermediate representation that was translated to actual machine code at runtime. This meant that when IBM changed the underlying processor architecture (from CISC to PowerPC in 1995), existing compiled programs continued to run unmodified — they were retranslated. No recompilation required. No source code changes required. Existing applications: unaffected.
Object-based single-level storage: the AS/400 treats all objects — files, programs, user data, system objects — as part of a single address space managed by the operating system. There is no file system in the traditional sense. The system manages storage, handles backups, and maintains object integrity automatically. This architecture eliminated entire classes of security vulnerabilities that operating system file security has struggled with for decades.
Why It Never Dies
Walk into a regional bank, a mid-sized manufacturer, or a government agency. Somewhere in their data center there is a machine running IBM i. The application running on it was likely written in RPG or COBOL between 1990 and 2005 by programmers who may no longer work there. It runs correctly. It has run correctly every business day since it was deployed.
The AS/400 backward compatibility commitment means that software written for the original 1988 platform — compiled 35 years ago — runs on modern Power10 hardware without modification. This is not a theoretical claim. It is documented in production deployments around the world.
This is the museum's exhibit on what correct engineering looks like in practice: a platform that made backward compatibility a first-order architectural constraint, paid an engineering cost to implement it thoroughly, and earned a 35-year track record of unbroken production deployments.
The Pattern
The AS/400's longevity is the constructive counterpoint to every exhibit in the museum. Where Complexity Accretion documents software accumulating technical debt that eventually breaks under its own weight, the AS/400 documents a platform that managed the complexity horizon through abstraction layers that were designed, not accumulated.
The TIMI layer is the key: it separates what the application does from how the hardware does it. Every time IBM changed the underlying hardware, the applications were unaffected because the abstraction layer absorbed the change. This is the same principle that makes Java "write once, run anywhere" — but the AS/400 implemented it in 1988, proprietary, and made it work for 35 years of hardware generations.
There are AS/400 applications older than most software engineers running in production today. The software is not wrong. Katie's Law explains why modern systems aren't this durable: making backward compatibility a first-order commitment is hard. The AS/400 team did the hard work. Most teams don't.