Home > Computing

In 1964, IBM risked its entire corporate empire on the System/360, a chaotic gamble to make all of its future machines compatible with the same software — and the architecture proved so robust that modern enterprise mainframes today are still running sections of binary code written more than sixty years ago

By Make Tech Easier Editorial Team
In 1964, IBM risked its entire corporate empire on the System/360, a chaotic gamble to make all of its future machines compatible with the same software — and the architecture proved so robust that modern enterprise mainframes today are still running sections of binary code written more than sixty years ago Featured Image

On the morning of April 7, 1964, in a coordinated announcement broadcast to more than 100,000 people gathered in 165 cities around the world, IBM did something almost no large company had ever done.

It bet itself.

The product it was unveiling was called the System/360 — a family of six computers, fifty-four peripherals, and a new operating system, all designed to do something no computer family had ever done before. They would all be compatible. Software written for the smallest, cheapest model would run, without modification, on the largest, most expensive one. Customers who outgrew their machine could simply buy a bigger one and keep their existing programs.

It sounds obvious now. In 1964, it was revolutionary. And IBM had spent so much money trying to build it — roughly $5 billion, more than was spent on the Manhattan Project — that if it failed, the company would not survive.

The gamble paid off. The System/360 became the most successful computer family in history. And the architectural decisions IBM’s engineers made in the early 1960s are still, six decades later, running the backend of the global economy.

The mess that came before

To understand why System/360 was so radical, you have to understand the chaos it replaced.

By the early 1960s, IBM had four major computer product lines, each with its own architecture, its own operating system, its own programming tools, and its own peripherals. The 1401 was a small business machine. The 7070 was a large business machine. The 1620 was a small scientific computer. The 709x series was a large scientific machine.

None of them could talk to each other. Software written for one was useless on another. A customer who outgrew their 1401 couldn’t simply upgrade — they had to throw out everything and start over, rewriting all their applications, retraining their staff, replacing all their peripherals.

This was bad for customers. It was, surprisingly, also bad for IBM. Maintaining four entirely separate development teams, four operating systems, four sets of tools, and four ecosystems of peripherals was enormously expensive. As software became more complex through the early 1960s, the cost of maintaining four incompatible product lines was becoming structurally unsustainable.

IBM’s leadership reached a conclusion that, at the time, seemed almost insane. The company would scrap all four product lines and replace them with a single, unified family.

The bet that almost broke the company

The development of System/360 was, by every honest account, a near-disaster.

The estimated cost ballooned to $5 billion — in 1962, IBM’s total revenue was just $2.5 billion. Internal politics nearly killed the project several times. A competing internal proposal called the IBM 1470 threatened to fragment the company’s strategy. The software effort, in particular, was a famous catastrophe: the OS/360 operating system fell years behind schedule and inspired the most famous book ever written about software development, Fred Brooks’s The Mythical Man-Month, which documented the chaos of trying to coordinate thousands of programmers on a single enormous codebase.

CEO Thomas Watson Jr., who had personally driven the project, became known for the phrase that would attach itself to the entire endeavour. He had, he said, “bet the company on it.” If the System/360 failed, IBM was finished. There was no Plan B. The development costs had consumed too much capital and the existing product lines were being deliberately retired to make way for the new family.

The April 7, 1964 announcement was the moment of truth. And the response — orders flooding in from across the world — was overwhelming. IBM’s gamble had been correct. Customers wanted the freedom to upgrade their hardware without rewriting their software. They wanted a single, coherent platform. They were willing to pay a premium for it.

Within years, the System/360 had become the standard against which all other computers were measured. The good-to-great author Jim Collins later ranked it as one of the top three business accomplishments of all time, alongside Ford’s Model T and Boeing’s 707.

The promise IBM has kept for sixty years

Here is the genuinely remarkable part of the story.

The compatibility commitment IBM made in 1964 — that software written for the System/360 would run on any future machine in the family — has been honoured continuously for more than sixty years. The architecture has evolved. The System/360 became the System/370, then the System/390, then the zSeries, then the z/Architecture mainframes IBM sells today.

But the instruction set has remained backward-compatible the entire way. A program compiled for an IBM mainframe in 1970 will, with minor adjustments, run on the IBM z17 mainframes being shipped to banks and insurance companies in 2026. COBOL applications written in the 1970s and 1980s for System/370 and System/390 hardware are still running, today, on modern z/OS systems — performing the same payroll calculations and account reconciliations they were written to do half a century ago.

This is not an accident. It is the result of a deliberate, continuous, very expensive engineering commitment by IBM to never break the compatibility promise made in 1964. Every new mainframe generation, for sixty years, has had to support every program written for every previous generation. The cost of doing this is enormous. The value of doing it is even larger: it’s the reason the world’s largest banks, airlines, and insurance companies still trust IBM mainframes for their most critical workloads. The software they wrote decades ago still works, and they can plan their next decade of investment knowing it will continue to work.

Why this still matters

The System/360 is not just an artifact of computing history. It is the reason the modern financial system still functions the way it does.

The COBOL banking systems that process trillions of dollars of daily transactions run on z/Architecture mainframes — the direct descendants of the System/360. The same lineage holds for major airline reservation systems, government tax-processing infrastructure, and the back-office systems of most of the Fortune 500.

When IBM bet the company in 1964, they were not just betting on a single product. They were betting on a commitment — the idea that customers would pay a premium for stability, and that stability, if maintained for long enough, would become the most valuable thing a technology company could offer.

Sixty-two years later, that bet is still paying off. And somewhere in the world, right now, a modern IBM mainframe is running a piece of code that was written before the moon landing — exactly as it was promised it would.

Subscribe to our newsletter!

Our latest tutorials delivered straight to your inbox

Make Tech Easier Editorial Team Avatar
Make Tech Easier Editorial Team
The Make Tech Easier Editorial Team produces content on tech tutorials, software guides, and practical solutions for everyday computing problems. We work alongside our team of named tech writers whose individual bylines appear on their work. Articles under this byline reflect collective editorial work. Make Tech Easier takes editorial responsibility for content under this byline. For more on how we work, see our editorial guidelines.

Read next

In 1982, a Soviet pipeline suddenly exploded with the force of a tactical nuclear weapon, and the disaster was traced back to a stolen piece of Canadian pipeline software — and years later, it was revealed the CIA had intentionally allowed the KGB to steal the code, after subtly altering the software’s logic to trigger a catastrophic pressure surge months down the line.
In 1988, a graduate student launched an experimental script to measure the size of the internet, and a tiny programming oversight caused it to accidentally replicate out of control — infecting ten percent of all connected computers in hours and creating the world’s first massive digital crisis.
Stunning capture of the Orion Nebula (M42) with sparkling stars and vibrant emission clouds.
The Voyager 1 spacecraft launched in 1977 is now over 15 billion miles from Earth, and a radio signal from NASA takes more than 22 hours to reach it, meaning every command is really an instruction for where the probe will be by tomorrow
Every time you book a flight or check a hotel room, your request is routed through a green-screen mainframe system that traces back to the 1960s — and the entire multi-billion-dollar travel industry still relies on this ancient digital foundation because replacing it would be enormously expensive, dangerous, and slow
In 1997, a team of engineers hid an entire flight simulator inside the code of Microsoft Excel as an unlisted “Easter egg” — and to this day, it remains one of the most sophisticated pieces of hidden software ever secretly shipped to millions of corporate computers
A 65-year-old programming language called COBOL still quietly processes over $3 trillion in banking transactions every single day — and because the original engineers are rapidly retiring, banks are scrambling to pay younger developers fortunes just to keep the ancient infrastructure from breaking
Stanford scientists just built a room-temperature quantum device that uses “twisted light” to connect electrons and photons — an long-sought breakthrough that could finally take quantum computing out of extreme sub-zero labs and into everyday devices
When Microsoft was developing Windows 95, developers discovered that SimCity had a severe memory bug that caused it to crash on the new operating system—but instead of forcing the game studio to fix it, Microsoft engineers actually rewrote the core Windows 95 source code to detect if SimCity was running and safely allocate memory for it.