- Remembering a Place You've Never Been
- How They Know: The Science of Inherited Navigation
- Multigenerational Knowledge Transfer: Knowledge Management
- Way-finding and Developer Decision-Making
- Michael Polanyi: We Know More Than We Can Tell
- Migration Strategy and Technical Migration
- Mariposas Monarca: The Souls That Return
- Resilience and Incident Response
- You Are a Butterfly: The Multigenerational Codebase
- The Super Generation: Choosing to Carry More
- Open Source: The Quintessential Multigenerational Project
- Five Practices for Building Multigenerational Developer Knowledge
- What the Butterfly Teaches
- References
Remembering a Place You've Never Been
Every autumn, hundreds of millions of Monarch butterflies (Danaus plexippus) begin flying south from Canada and the northern United States. Their destination is a specific stand of Oyamel fir trees in Michoacan, Mexico — approximately 4,500 kilometers away.
The distance is not the astonishing part. The astonishing part is this: not a single one of these butterflies has ever been there before.
The monarch lives four to six weeks. But butterflies born in late summer enter a special biological state called diapause — reproductive arrest, combined with intensive fat accumulation — and live eight to nine months instead. This "super generation" completes the autumn migration to Mexico. In spring, they begin flying north again, laying eggs along the way before dying. Their offspring continue north. A third generation. A fourth. By autumn, this fourth generation finds its way back to the same Oyamel forest in Mexico that their great-great-grandparents left.
A place they have never been. A place their great-great-grandmothers once departed from.
How They Know: The Science of Inherited Navigation
Lincoln Brower spent his career from the 1960s until his death in 2014 documenting monarch migration. He established that this is not simple instinct but a sophisticated navigational system.
The Reppert Lab at the University of Massachusetts revealed that monarchs use two compasses simultaneously. The first is a sun compass — monarchs compute direction from the sun's position integrated with the time of day. Remarkably, this sun compass is coupled to a circadian biological clock located in the antennae themselves.
The second is magnetic navigation. A 2021 study found magnetic receptors in monarch antennae, confirming that Earth's magnetic field serves as an additional navigational reference.
But these two mechanisms still don't fully explain how a butterfly navigates to a specific forest on a specific mountain range it has never seen. There is something else — something science has not yet fully characterized. Knowledge transmitted across generations in ways we do not yet understand.
Multigenerational Knowledge Transfer: Knowledge Management
The most remarkable aspect of the monarch migration is that no single butterfly completes the full journey. The route spans four generations, each responsible only for its own segment. Yet the system works. Route information encoded in genes is transmitted from generation to generation.
The same thing happens in software teams. The original architect moves on, early members scatter to other teams, new developers join. But the project keeps moving forward. How? Because knowledge has been captured in appropriate media.
Nonaka Ikujiro and Takeuchi Hirotaka's SECI model describes four modes of knowledge conversion:
- Socialization: Tacit to tacit. Absorbing a senior developer's instincts through pair programming and code review
- Externalization: Tacit to explicit. Writing ADRs, documenting design intent in wikis
- Combination: Explicit to explicit. Synthesizing multiple documents into an onboarding guide
- Internalization: Explicit to tacit. Reading documentation and then writing code until the knowledge becomes embodied
Monarchs transmit knowledge through genetics. Developers have more options:
- Notion, Confluence: Team wikis, design documents, meeting notes
- GitHub Wiki: Documentation close to the code
- ADR (Architecture Decision Records): Recording the reasoning behind decisions
- README, CONTRIBUTING guides: The compass at the project's entry point
The tool is not the point. The point is the discipline of leaving records so the next generation of butterflies can find the path.
Way-finding and Developer Decision-Making
Monarchs combine a sun compass, magnetic fields, and as-yet-undiscovered landmarks to navigate. They do not rely on a single signal. It is a multi-compass strategy that integrates several inputs.
Developer decision-making works the same way. Good architecture decisions are never based on a single criterion. They reference multiple compasses simultaneously:
- Architecture principles: SOLID, DRY, KISS — these provide the broad direction
- Design patterns: Proven solutions to recurring problems, like the butterfly's genetic routes
- Team conventions: Coding style, branching strategy, PR rules — agreed-upon practices within the team
- Business context: Sometimes business constraints determine direction even when the technical optimum lies elsewhere
Decision Records serve as navigational aids for future teams. When you record why a particular path was chosen, the next generation of developers avoids repeating the same deliberation from scratch.
Code is not written only for the compiler. Code is a message to future developers. Variable names, function names, module structure — all of these are waypoints for the next butterfly that will fly this route.
Michael Polanyi: We Know More Than We Can Tell
The Hungarian-British philosopher Michael Polanyi wrote in his 1958 Personal Knowledge: "We can know more than we can tell."
He called this tacit knowledge — the kind of knowing that resists explicit articulation. How to ride a bicycle. How to recognize a face. The intuition of an experienced physician who senses something is wrong before any diagnostic test confirms it. These are genuine forms of knowledge, but they cannot be fully verbalized.
The monarch's navigational knowledge is tacit knowledge at its most extreme. It is encoded in DNA, in neural architecture, in systems we don't yet understand. The butterfly cannot explain what it knows. But it flies 4,500 kilometers to exactly the right forest.
Developers carry tacit knowledge too. Why this architecture will cause problems in three years. Why this API design will confuse users even though it looks reasonable on paper. Why this PR, technically correct, will become technical debt. These intuitions came from somewhere — from the code written by developers before you, from the architectures that succeeded and failed before you arrived, from the accumulated experience of a community you are part of.
Migration Strategy and Technical Migration
The English word "migration" applies to both monarch butterfly journeys and technical system transitions. This is no coincidence. Both involve large-scale movement from one state to another, requiring planning and phased execution.
Examining the monarch's migration strategy reveals striking parallels with technical migration.
Stopover Sites
Monarchs do not fly 4,500 kilometers in one go. They stop at intermediate sites to feed on nectar and replenish energy. The wildflower fields along the Texas coast are a critical stopover. If these sites are destroyed, the entire migration is at risk.
The Strangler Fig Pattern: Gradual Migration, Butterfly-Style
The Strangler Fig pattern, named by Martin Fowler, replaces a legacy system not all at once but by gradually wrapping it with new functionality until the old system is fully displaced. This is how the monarch completes its journey — not in one generation but across four, each segment validated before the next begins.
Database migrations, framework upgrades, cloud transitions — incremental approaches work well in all of these:
- Big bang migration: Switch everything at once. High risk, fast timeline
- Incremental migration: Transition in phases. Each phase can be validated. Rollback is straightforward
The butterfly's lesson is clear: do not ask a single generation to cover 4,500 kilometers alone. Design stopover sites, validate each segment, and ensure the full journey connects end to end.
Mariposas Monarca: The Souls That Return
In Spanish, the monarch butterfly is the mariposa monarca. For indigenous communities near the Oyamel forests of Michoacan, these butterflies have long been considered sacred. Traditional belief holds that the souls of the dead return in early November — during Dia de los Muertos, the Day of the Dead — in the form of monarch butterflies.
"El viaje es la recompensa" — the journey is the reward. This Spanish expression, connected to the cultural significance of the monarch migration, captures something true: it is not only the destination that matters, but the journey itself. The spectacle of hundreds of millions of butterflies coloring the sky is itself a purpose, not merely a means to an end.
In Japanese, wataridori means migratory bird — but the word carries a cultural weight that reflects the deep Japanese appreciation for seasonal journeys. The bird that leaves in autumn and returns in spring; the migration as a living expression of time's rhythm. This same appreciation for cyclic movement, for the beauty of returning, extends to the monarch butterfly and its remarkable journey.
Resilience and Incident Response
The monarch migration is never smooth. Storms, predators, habitat destruction, climate change — every year, countless threats disrupt the journey. Yet the migration has persisted for thousands of years. Why? Because the monarch migration system has resilience built in.
Monarchs do not depend on a single route. When winds are strong, they adjust their path. When a stopover site is destroyed, they find alternatives. Failure is frequent at the individual level, but the system survives at the population level.
The same principles apply to software systems.
Chaos Engineering
Netflix's Simian Army deliberately injects failures into systems to test their recovery capability. Chaos Monkey randomly terminates servers. Latency Monkey injects network delays. Just as monarchs encounter storms every year, systems must experience failures proactively to survive real incidents.
The Circuit Breaker Pattern
Michael Nygard's circuit breaker pattern prevents failures from cascading. When a dependent service stops responding, calls are cut off after a threshold of failures. It mirrors the way a butterfly detects a dangerous route and reroutes.
Graceful Degradation
Even when the full system is not operating perfectly, core functionality is maintained. Just as the monarch migration reaches its destination via alternative routes when some stopovers are lost, a system provides minimal service to users even when parts of it have failed.
The core lesson: design systems that survive failure, not systems that prevent failure. This is the strategy monarchs have proven over thousands of years.
You Are a Butterfly: The Multigenerational Codebase
Now the most important connection.
Think about the codebase you work in. Someone who came before you started it. Some architectural decisions have reasons that are now obscure. Some variable names are perfectly apt if you know the context and baffling if you don't. Some legacy code looks strange today but was the right choice given constraints that no longer exist and have not been documented.
You are flying a migration path that earlier generations of butterflies established.
And someone will come after you. They will see your code. Your decisions, your solutions, your bugs, your comments — all of it becomes part of the navigational system for the next generation of developers working in your codebase.
You may be working on a project you will never see completed. That is not a tragedy. It is the nature of all meaningful work. The cathedral builders of medieval Europe knew they would not live to see the spires finished. The mathematicians who established the foundations of computer science never saw the internet. What they built became the migration path for those who came later.
The Super Generation: Choosing to Carry More
Monarch super-generation butterflies don't just live longer. They live differently. Reproductive drive is suppressed. Fat reserves are prioritized. Their biology reorganizes around the mission of distance.
Developer communities have their own super generations. The maintainers who steward open-source libraries that millions depend on. The people who write technical blog posts explaining what they just spent three months learning. The conference speakers who crystallize community knowledge into transmissible form. The mentors who invest deliberate time in someone else's growth. These people are not optimizing for personal productivity — they are carrying the migration path forward for everyone who comes next.
Becoming part of this is not a sacrifice. It is a different kind of reward.
Open Source: The Quintessential Multigenerational Project
Just as the monarch migration is completed across four generations, great open-source projects grow through successive waves of contributors.
The Linux kernel: Since Linus Torvalds started it in 1991, tens of thousands of contributors have participated over more than 30 years. Most of the early contributors have long since moved on, but the code and design decisions they left behind still form the kernel's skeleton. No single person completed the journey. Yet the kernel powers the world's servers, smartphones, and embedded devices.
The Boy Scout Rule: "Leave the campground cleaner than you found it." Robert C. Martin applied this principle to software, and it aligns precisely with the monarch lesson. You do not need to refactor the entire codebase. Just leave it in a slightly better state as you pass through.
Contributing meaningfully to open source does not require grand gestures:
- Fix a typo in the documentation
- Make an error message clearer
- Add one line of test coverage
- Write detailed reproduction steps on an issue
These small contributions accumulate into ecosystems. You are part of a journey you will not complete. That is the nature of open source, and the nature of the monarch migration.
Five Practices for Building Multigenerational Developer Knowledge
1. Record why, not just what (Architecture Decision Records)
The most valuable documentation is the documentation of reasoning, not implementation. Architecture Decision Records (ADRs) are a practice of leaving letters to your future colleagues: "We chose Y over X because, at the time, we faced constraint Z." One such record can save a future developer hours of archaeology — and prevent a well-meaning future refactor from destroying a decision that solved a real problem.
2. Write code as letters to the future
When you comment, explain intention — not mechanics. When you name a variable or function, think about the developer who will read it without you present to explain. Good code is good communication across time. The reader is real. Write to them.
3. Contribute to open source as legacy-building
Every open-source contribution is participation in a multigenerational migration. A bug fix, a documentation improvement, a new test case — these accumulate into ecosystems. You are contributing to something you will not complete. That is not a reason to withhold contribution; it is the very definition of what open source is.
4. Convert tacit knowledge to explicit knowledge
The things senior developers describe as "just feeling right" — code smell, architectural smell, the intuition that a performance issue is ahead — practice explaining these. Write them down imperfectly. Share them incompletely. The attempt to articulate tacit knowledge is itself the practice that makes it more shareable. Polanyi knew that tacit knowledge could never be fully explicit. But it can be more explicit than it currently is.
5. Treat onboarding as migration-path maintenance
A new team member arriving is a new butterfly joining the migration. Help them find the path. Documentation, pair programming, code tours, architecture walkthroughs — these investments build the navigational system that every future developer will rely on. Good onboarding is not just kindness. It is the mechanism by which institutional knowledge propagates across generations.
What the Butterfly Teaches
The monarch butterfly cannot explain where it is going or why. But it flies 4,500 kilometers to exactly the right forest, navigating by the sun and the earth's magnetic field, guided by something encoded in its very being by generations of butterflies it never met.
We developers carry the same kind of knowledge. Intuitions about what will age well, what will break under pressure, what will confuse the users who come later — these intuitions come from the developers who came before us. From code they left. From posts they wrote. From talks they gave. From systems they built that we now maintain.
We are somewhere in the middle of a multigenerational journey. The butterflies before us made the path. The butterflies after us will extend it.
The code you write today, the knowledge you share, the documentation you leave — these become someone else's compass.
Fly.
Quiz: Monarchs and Developers
Q1. How many generations does it take to complete the monarch's Canada-to-Mexico round-trip migration?
A) 1 generation — the super generation completes the round trip
B) 2 generations — parent and offspring split the journey
C) 4 generations — each generation covers its own segment
D) 10+ generations — dozens of generations are required
Answer: C. The spring northward return takes three generations, and the autumn southward migration is completed by a single super generation. The full cycle spans four generations.
Q2. Why is the Strangler Fig pattern analogous to monarch migration?
A) Both replace everything at once
B) Both gradually displace the old with the new
C) Both involve fig trees
D) Both revert to the original state on failure
Answer: B. The Strangler Fig pattern has a new system gradually wrap and replace the legacy system. This mirrors how monarchs complete their journey not in one generation but incrementally across four, validating each segment along the way.
Q3. In the Nonaka-Takeuchi SECI model, what type of knowledge conversion occurs when you absorb a senior developer's code review instincts through pair programming?
A) Externalization — tacit to explicit
B) Socialization — tacit to tacit
C) Combination — explicit to explicit
D) Internalization — explicit to tacit
Answer: B. Directly experiencing and absorbing a senior developer's judgment and instincts through pair programming is a tacit-to-tacit transfer, which the SECI model calls Socialization.
References
- Brower, L. P. (1996). Monarch butterfly orientation: missing pieces of a magnificent puzzle. Journal of Experimental Biology, 199(1), 93-103.
- Reppert, S. M., Gegear, R. J., & Merlin, C. (2010). Navigational mechanisms of migrating monarch butterflies. Trends in Neurosciences, 33(9), 399-406.
- Guerra, P. A., Gegear, R. J., & Reppert, S. M. (2014). A magnetic compass aids monarch butterfly migration. Nature Communications, 5, 4164.
- Polanyi, M. (1958). Personal Knowledge: Towards a Post-Critical Philosophy. University of Chicago Press.
- Nonaka, I., & Takeuchi, H. (1995). The Knowledge-Creating Company. Oxford University Press.
- Fowler, M. (2004). Strangler Fig Application. martinfowler.com.
- Nygard, M. T. (2018). Release It! Design and Deploy Production-Ready Software (2nd ed.). Pragmatic Bookshelf.
- Martin, R. C. (2008). Clean Code: A Handbook of Agile Software Craftsmanship. Prentice Hall.
- Rosenthal, C., & Jones, N. (2020). Chaos Engineering: System Resiliency in Practice. O'Reilly Media.