Every developer ships them, every phone nags you to install them, and every security bulletin is measured by how fast one arrives. But nobody stops to ask why a software fix is called a patch. The answer is refreshingly literal: for the first two decades of computing, a patch was a physical object you cut, taped and re-punched by hand.
When a program was a pattern of holes
In the 1940s and 1950s, programs did not live in files. They lived as holes.
A program was punched into a deck of cards or a long reel of paper tape, and the machine read it by detecting where the holes were and were not. The code was not a representation of the instructions — the perforations were the instructions. Change the holes and you changed the program.
That physicality created a very practical problem. If you found a bug in a 300-foot reel of tape, you could not simply edit a line and recompile. The wrong instruction was a wrong pattern of holes somewhere in the middle of a spool, and re-punching the entire program to fix a few bytes was hours of work.
The fix was a piece of tape
So engineers did the obvious thing. They covered the mistake with a small piece of adhesive tape or card stock — a patch, in the same sense as a patch on a pair of trousers — blanking out the incorrect holes. Then they punched the correct pattern into the patch itself.
The program now had a physical repair stuck to its surface. Operators sometimes kept a roll of patching tape next to the machine the way a mechanic keeps a roll of duct tape. On punched-card systems the equivalent trick was to pull the offending card and replace it with a corrected one, and a stack of those corrections was likewise called a patch deck.
The name was descriptive, not metaphorical. It only became a metaphor later, once the tape disappeared and the word did not.
Why the word survived the medium
By the 1960s and 1970s, programs had moved to magnetic storage and there was nothing left to physically patch. But the shape of the operation stayed exactly the same: rather than rebuild and redistribute an entire program, you shipped a small correction that modified the existing one in place.
That was still a strong practical constraint. Distribution was slow and expensive, memory was scarce, and full rebuilds were risky. A patch — a minimal, targeted change to code that already exists in the field — remained the cheapest way to fix a defect. The engineering economics that produced the sticky tape produced the software patch too, so the term carried straight through into modern practice.
The OTA update is the same idea, at fleet scale
Nowhere is that lineage clearer than in embedded and IoT work, where the "field" is a literal one.
When you deploy a few thousand sensors, controllers or gateways, you inherit the exact problem the tape-patching engineers had: the code is already out there, physically, and rebuilding it from scratch is prohibitively expensive. The modern answer is the over-the-air (OTA) firmware update, and the constraints rhyme with 1955 in ways that surprise people new to embedded development:
- The device may be memory-constrained. A microcontroller like the ESP32 typically partitions its flash into two application slots (A/B), so the new image is written into the inactive slot while the current firmware keeps running.
- The update must be atomic. A device that loses power halfway through a write cannot be left with half a program. The bootloader only switches slots once the new image is fully written and verified.
- It must roll back. If the new firmware fails to boot or fails its first health check, the bootloader reverts to the previous slot. This is the single most important feature in the whole chain, because it is what makes a bad patch survivable.
- It must be authenticated. An unsigned update path is a remote code execution vulnerability with extra steps. Signed images plus secure boot mean a device only runs firmware your build system produced.
- It must be staged. Push to one percent of the fleet, watch the telemetry, then widen. A patch deployed to every device simultaneously is a single point of failure.
Get that right and a critical security fix is an afternoon's staged rollout. Get it wrong and it is a technician driving to every installation site — which, for a few thousand devices spread across an archipelago, is not a support cost so much as an existential one.
The lesson from the tape
The reason the punched-tape story is worth telling is not nostalgia. It is that those engineers designed for repair as a first-class concern, because the cost of not doing so was immediately, physically obvious to them. They kept the patching tape next to the machine.
Modern IoT teams often lose that instinct, because the cost is deferred. The update path is easy to postpone during prototyping and brutally expensive to retrofit after deployment, once the enclosures are sealed and the devices are on a customer's roof.
We design connected products with the update path in the architecture from the first sprint — secure boot, signed images, A/B partitioning and automatic rollback — so that a field fix stays a deploy rather than a site visit. If you are building a device fleet and the answer to "how do we patch this later?" is still unwritten, get in touch and let us work through it before the hardware ships.
Because the word has not changed in seventy years, and neither has the job: fix what is already out there, without pulling it all back in.
Top comments (0)