I was in the war room at 2 AM, staring to the aftermath of what was supposed to be our next evolutionary leap.
We pushed the final piece of our cloud migration at midnight.
By 12:07 AM, 60% of our customers couldn’t log in.
By 12:15 AM, the rollback plan failed because the servers it was meant to restore to didn’t even exist anymore.
Despite the thorough migration plan, the old system was gone ... extinct in a single night, and our “evolved” architecture had nowhere to run.
We didn't anticipate the blind spots, and the post-mortem read like a crime scene report where we were both the victim and the suspect.
That’s when I realised Darwin’s theory applied to software too: Software behaves like living organisms.
They survive in hostile, sudden fast-changing environments where threats can be idiocy, market shifts, new regulations, and smarter/hungrier competitors.
And just like in nature, survival is not about being perfect, but about adapting faster than the next guy
Darwin didn’t code, but if he did, "On the Origin of Species" would’ve had a chapter called “Preservation of the worst through unnatural selection”.
Natural selection in architecture
“A complex system that works is invariably found to have evolved from a simple system that worked.”
— John Gall, Gall's Law
In nature, traits that help survival spread. In architecture, it’s the same.
That meticulous CI/CD pipeline you bled weekends to perfect? Now it’s the default playbook for every new deployment.
Bad traits — like half-baked scripts or fragile pipelines — don’t age gracefully; instead, they either get refactored out or blow up in production so loudly that even non-technical managers remember their name.
Design patterns are the “genes” of software, they get passed on because they solve recurring problems efficiently. Patterns become survival tools copied across projects because they increase architectural fitness.
Remember the rise of the Circuit Breaker pattern? It started as a niche fix for flaky network calls but spread rapidly once teams saw it could save entire services from cascading failures.
I still remember deploying one in production and watching error rates nosedive in minutes like installing an immune system overnight.
Good code/patterns spread.
Bad ones get turned into horror stories whispered to every fresh recruit.
Survival of the adaptable
“By its very nature every architecture is a statement about what we expect to remain constant and what we admit may vary.”
— Len Bass, Software Architecture in Practice
In evolutionary terms, “fittest” doesn’t mean the strongest or the fastest; it means the ones that adapt best to change.
Netflix didn’t survive because it found a perfect design. It survived because it kept mutating from mailing DVDs to streaming to global content delivery; same core DNA, constantly evolving traits.
Your architecture’s fitness isn’t fixed; instead, it depends on a shifting landscape of requirements, market forces, and competition. What’s fit today can become a liability tomorrow if the environment changes.
However, not every mutation is a risk; indeed, some are breakthroughs. Occasionally, a daring experiment or rewrite introduces innovations that shift the architecture into new territory, just like beneficial mutations in nature.
Spotify’s “Squad” model was a radical mutation, reshaping how architecture and teams evolve together. It unlocked adaptability legacy org charts could never achieve.
Your stack isn’t a life partner. The day it stops adapting, it’s over.
Extinction events
Nature has asteroid strikes. Architecture has cloud migrations, new compliance regimes, and paradigm shifts that rewrite the rules overnight.
If your architecture can’t adapt, it’s game over.
Some systems are still running perfectly; conversely, they are irrelevant in the modern ecosystem, much like a fossil perfectly preserved.
Remember when Flash ruled the web? Exactly.
Flash’s demise wasn’t just technical, it was an ecosystem collapse. Designers, ad networks, entire workflows died with it.
When Apple banned Flash on iOS, it triggered an extinction event. Those that couldn’t pivot to HTML5 either rewrote from scratch or vanished.
Perfect and irrelevant is still dead.
Speciation and divergence
Sometimes extinction doesn’t happen all at once. Sometimes a system just… drifts apart.
A forked codebase is like a species splitting into two. At first, they can interbreed; however, over time each adapts to its environment and loses compatibility with the other.
Internal library forks do this too: speak enough versions, and your team spends more time translating than building features.
Every uncontrolled fork is an unplanned migration project in disguise.
Co-evolution
Species evolve together: bees with flowers, predators with prey.
Your architecture evolves with user habits, partner APIs, and industry protocols.
Miss the signs, and you’ll be designing for a world that no longer exists.
When your environment shifts and you don’t, you’re not stable ...
You’re extinct.
The ghost features
Nature has the appendix. Architecture has the “temporary” module that’s been there for a decade.
Once useful, now it just sits there... sometimes harmless, sometimes a liability that can rupture mid-release.
The hard part is knowing which scars are structural and which are just baggage.
We had one of these, a ‘temporary’ cron job from 2012.
No one touched it until it woke up one night and started emailing thousands of blank invoices.
Some relics hold the system together. Others are ticking bombs.
Mutation rate management
Too few mutations, and you stagnate. Too many, and the organism collapses.
In practice, mutations are framework swaps, dependency upgrades, and full architectural rewrites.
“The architecture of a software system is the shape given to that system by those who build it… The strategy behind that facilitation is to leave as many options open as possible, for as long as possible.”
— Uncle Bob, Clean Architecture
Healthy teams control the mutation rate: enough to adapt, not enough to destabilise.
Mutation isn’t about speed, it’s about surviving change.
Ecosystem thinking
No organism thrives alone.
Your architecture depends on the health of its ecosystem: infrastructure, integration with partner systems, CI/CD, tooling, and the skills of the humans running it.
Neglect that, and you’re basically poisoning your own water supply.
In instance, Linux didn’t just adapt, it became the backbone of a global ecosystem. Docker, Ansible, and Prometheus co-evolved alongside it, while proprietary stacks that refused to play along struggled to keep up.
If your ecosystem is dying, your architecture is next.
Specialisation vs. generalism
Specialists dominate… until their environment shifts. Generalists survive longer in more environments but rarely dominate.
A low-latency trading engine crushes finance workloads, but move it to healthcare and watch it choke.
Architectural resilience means knowing your habitat, and how it might collapse.
Architects don’t just react to their environment, they build the niche their business thrives in by shaping custom architectures to fit unique needs.
Build for your habitat, but have an escape plan.
Final thought
Darwin’s lesson for architects is simple: stability isn’t the goal, survivability is.
You’re not building monuments. You’re cultivating living systems in hostile territory.
Systems live or die not by perfection, but by their ability to adapt when the environment shifts.
The right question isn’t ‘Is it perfect?’
It’s ‘Will it survive the next mutation?’
If you liked this post, follow me on my blog for more.
Top comments (0)