Legacy Archaeology — Trivia & Interesting Facts¶
Surprising, historical, and little-known facts about working with legacy systems and code archaeology.
COBOL systems still process 95% of ATM transactions and 80% of in-person transactions¶
As of 2024, an estimated 220 billion lines of COBOL are still in active production, processing the majority of the world's financial transactions. During the COVID-19 pandemic, US state unemployment systems (many written in COBOL in the 1970s-80s) crashed under load, and governors publicly appealed for COBOL programmers. The average age of a COBOL programmer is over 55.
The Y2K remediation effort cost an estimated $300-600 billion globally¶
The Year 2000 bug, caused by storing years as two digits, required the largest coordinated software remediation effort in history. An estimated 300,000+ programmers worked on Y2K fixes worldwide. Some organizations chose to "window" dates (interpreting 00-49 as 2000-2049 and 50-99 as 1950-1999) rather than fully fix them, kicking the problem to 2050. Those deadlines are now approaching.
The oldest continuously running software is from the 1950s-60s and nobody fully understands it¶
Some military and government systems have been running continuously since the 1960s, with modifications accumulated over 60+ years. The US Department of Defense still maintains systems written in JOVIAL (Jules Own Version of the International Algebraic Language), a language created in 1959. The original developers are long retired or deceased, and the source code often has no documentation beyond the code itself.
"Archaeologist" is an actual job title at some tech companies¶
Several large organizations, including the BBC and various financial institutions, have created formal "software archaeologist" or "legacy system archaeologist" roles. These engineers specialize in reverse-engineering undocumented systems, reading dead programming languages, and understanding business logic that exists only in code nobody has read in decades. The role requires equal parts technical skill and detective work.
The Lindy effect suggests that long-surviving software will continue to survive¶
The Lindy effect, popularized by Nassim Nicholas Taleb, states that the longer a technology has survived, the longer its expected remaining lifespan. A system that has been running for 30 years is statistically likely to run for another 30 years. This has profound implications for legacy systems: the "temporary" system installed in 1995 is more likely to outlive the modern replacement being planned for it.
Reverse-engineering a legacy system often reveals undocumented business rules worth millions¶
When organizations attempt to replace legacy systems, they frequently discover that the old system encodes critical business rules that nobody documented and nobody currently in the organization fully understands. A classic example: a bank's legacy COBOL system applied a specific rounding rule to interest calculations that was required by a regulation from 1978 — a rule nobody remembered until the replacement system calculated different results and the bank was fined.
The Space Shuttle's flight software was maintained by a team that shrank from 260 to 16¶
NASA's Space Shuttle Primary Avionics Software System (PASS) was maintained by a team at IBM's Federal Systems Division that peaked at 260 people in the 1980s and gradually shrank to about 16 by the program's end in 2011. Despite the shrinking team, the software achieved an extraordinary defect rate of just 0.1 defects per 1,000 lines of code — one of the lowest ever measured for any software system.
Git blame and git log are the most powerful legacy archaeology tools available¶
For systems with version control history, git blame (or svn blame) reveals not just who wrote each line, but when and why (via commit messages). Experienced legacy archaeologists use git log --follow -p <file> to trace a file's complete history through renames, and git log -S "string" (the "pickaxe" option) to find when a specific piece of code was introduced or removed.
The "Chesterton's Fence" principle is the legacy archaeologist's golden rule¶
G.K. Chesterton's parable states: if you encounter a fence across a road, do not remove it until you understand why it was built. In legacy code, this means: never delete code that looks unnecessary until you understand why it's there. That mysterious sleep(3) might be working around a race condition that's not documented anywhere. That commented-out block might be activated during month-end processing.
Some organizations have lost the ability to build their own software from source¶
In extreme cases of legacy system decay, organizations discover that they can no longer compile their own source code. The build toolchain, compiler versions, or dependencies have been lost. The system runs from a binary that was last compiled by someone who left the company 15 years ago. This scenario is more common than most people believe, particularly in regulated industries like banking and defense.
The original Unix source code comments include profanity and personal frustrations¶
When the original Unix source code (Lions' Commentary on UNIX, 6th Edition, 1977) was eventually made public, it contained comments like "You are not expected to understand this" in the process switching code. Ken Thompson and Dennis Ritchie's original comments are remarkably candid. The tradition of brutally honest code comments is as old as programming itself.