What pyramids, bridges and beavers teach software architects

Software architecture is a young discipline. Engineers have been building pyramids and bridges for thousands of years and nature has been refining structures for millions. When a design decision gets hard, I step outside software and ask how a beaver, a bridge builder or a submarine designer would solve it. History helps too, often most where things went badly wrong.

Lessons from nature#

Beavers: shape the environment, then maintain it. A beaver doesn't fight the river; it dams it into a pond that keeps its lodge safe. And it never stops maintaining: the sound of running water, a sign of a leak, sends it straight back to patch the dam. Design with the environment your system runs in (its rate limits, maintenance windows and quirks) and keep listening for leaks. Small, regular repairs outlast heroic rebuilds.

Bears: prepare for the lean season. A bear builds reserves in autumn and survives the winter at a slower pace. Build headroom, caches, queues and runbooks in calm times, so that during an outage your system can run in a reduced mode, protect what matters most and recover fully afterwards.

Otters: know your keystones. Sea otters keep a favourite stone as a tool and, as a keystone species, protect whole kelp forests. Master a small set of tools. And know the small components everything silently depends on (certificates, DNS records, scheduled jobs): they deserve the most care, not the least.

Orcas and whales: roles and experience. Orcas hunt as coordinated pods guided by experienced elders; humpback whales hunt together with bubble nets, each playing a part. Clear roles and shared protocols let a team achieve what no individual can.

Kingfishers: change the shape of the problem. Japan's bullet trains boomed as they left tunnels until engineers modelled the train's nose on the kingfisher's beak. They didn't add power; they changed the shape so the problem went away. Good code works the same way: rethink the problem until the special case disappears.

Lessons from the builders before us#

The pyramids: logistics wins. The Great Pyramid's real achievement was organisation: quarries, boats, crews and supplies coordinated for decades. One of the oldest papyri ever found is a work log from its construction. In software, the supply lines behind the code (pipelines, environments and clear ownership) decide whether it gets built at all. And write things down.

Japan: renew and bend. The Ise Grand Shrine is rebuilt every twenty years so each generation learns the craft. Pagodas survive earthquakes by swaying rather than resisting. Rebuild environments from code and rehearse recovery so knowledge stays alive. Design systems that bend and recover rather than break.

Bridges: leave margins. The Brooklyn Bridge's cables were designed six times stronger than needed. When substandard wire was found already woven in, that margin kept the bridge safe. It still carries traffic today. Software receives bad inputs all the time; headroom, timeouts and validation are its margins.

Submarines: contain the failure. Watertight compartments let a flooded section be sealed off while the boat survives. Software borrowed the idea as the bulkhead pattern: isolate each dependency so one failure can't sink the whole system.

Soviet engineering: beauty and proven designs. Moscow's metro stations were built like palaces for everyday commuters, a reminder that tools people use daily deserve care and beauty. The Soyuz rocket has flown for decades by improving one proven design carefully rather than replacing it.

The Second World War: strategy at scale. Studying the war is not admiring any side of it, but its strategy holds clear lessons. Mission command gave units the goal and trusted them with the how, which is how I like to lead teams. The Blitzkrieg principles translate well: combine every skill in one team, focus on the decisive point, go around the fortress instead of attacking it head-on (replace legacy systems piece by piece) and never outrun your supply lines. And the simpler tank that could be built and repaired in the tens of thousands beat the complex one built in the hundreds.

Chernobyl: never switch off the safeguards. The 1986 disaster happened during a rushed test with safety systems disabled and a design flaw operators had not been told about. Never test in production without safeguards, test the failure path, share known weaknesses and be honest after incidents.

The short version#

1. Design with your environment and keep listening for leaks.
2. Build reserves before the lean season.
3. Know your keystones and give them the most care.
4. Give everyone a clear role.
5. Change the shape of the problem before adding more force.
6. Invest in logistics and write things down.
7. Rebuild regularly and bend rather than break.
8. Leave margins and contain failures.
9. Make everyday tools beautiful and evolve proven designs.
10. Lead with intent, focus on the decisive point and never outrun your supply lines.
11. Never switch off the safeguards.