Make Do and Merge: Ten Scarcity Tactics from Wartime Britain for Surviving Your Next Dependency Crisis
Every software team eventually meets its own valve shortage. A core dependency is abandoned. A licence expires the week before launch. A vendor is acquired and the pricing triples overnight. The instinct is panic; the wiser instinct is to borrow from a generation of British engineers who faced genuine scarcity and shipped anyway.
Between 1939 and the early 1950s, Britain ran one of the most extensive resource-constrained engineering programmes in history. Radio sets were repaired rather than replaced through official Repair, Wartime and Reuse schemes; household goods were patched under the 'make do and mend' ethos; salvage drives harvested components from anything that no longer worked. The lessons map onto modern dependency management with almost uncomfortable precision.
One: Know Exactly What You Have
Wartime salvage began with a census — every scrap of rubber, every serviceable valve, catalogued. Your equivalent is a software bill of materials. You cannot manage a shortage of dependencies you did not know you had, and transitive dependencies are the attic junk of most codebases.
Two: Repair Before Replace
The RWR schemes kept domestic radios alive by repairing rather than swapping, because new sets simply were not being made. When a dependency breaks on a new platform version, a small internal patch — maintained deliberately, documented honestly — is often cheaper and faster than a migration.
Three: Keep a Scrapheap
Every wartime workshop kept a bin of salvaged parts. Teams should do the same with code: a curated internal library of previously written, tested modules — parsers, retry logic, adapters — that can be pulled back into service. A component written once and remembered is a component you never pay for twice.
Four: Build Abstraction Where the Shortage Will Strike
You cannot abstract everything, but you can abstract the things most likely to disappear. Wrap your payment provider, your message queue, your cloud-specific storage calls behind thin internal interfaces. When the vendor changes the terms, you change one adapter, not two hundred call sites.
Five: Substitute Materials Deliberately
Wartime engineers substituted plastics for metal, and the results ranged from brilliant to disastrous — the difference being whether the substitution was tested or hopeful. Swapping a battle-tested library for a lighter alternative deserves the same rigour as the original choice: benchmarks, edge cases, a rollback path.
Six: Ration by Priority, Not by Preference
Clothing coupons allocated scarce fabric to need, not want. When a licence budget tightens, cut ruthlessly by actual usage data, not by which tool has the most enthusiastic internal champion.
Seven: Share Across the Household
Communal salvage and tool-sharing schemes meant one village might own a single item the whole street used. Internally, consolidate: if four teams each license a different PDF library, one shared component with one licence serves everyone for a quarter of the cost.
Eight: Design for Disassembly
Wartime furniture was built with joinery that could be taken apart and reassembled. Architect your services so that a component can be removed and replaced without structural damage — clean contracts, no leaking internals, no hidden coupling to a vendor's data model.
Nine: Document the Mend
A repaired radio with an undocumented modification was a hazard to the next repairer. Every internal patch or substitution gets a written record: what was changed, why, and what would trigger a proper replacement. Future-you is the next repairer, and future-you has forgotten everything.
Ten: Treat Scarcity as a Teacher
The most lasting output of the austerity years was not any single repair but a generation of engineers who understood their systems intimately, because they had been forced to open them up. Dependency crises, handled well, produce the same effect: teams that finally understand what their software is actually made of.
An Uncomfortable Closing Thought
None of this argues for engineering by permanent austerity. It argues for resilience — the quiet confidence that your system can survive the loss of any single supplier, dependency or licence. Wartime Britain did not choose scarcity, but it chose its response, and the response was discipline: know your inventory, keep your parts, abstract your seams, document your mends.
Your next vendor crisis is not a question of if. The only question is whether your codebase, like a well-repaired wireless set, will still be singing when it arrives.