Introduction
When building software we spend a lot of energy into designing systems that can operate, adapt and remain reliable under changing conditions. As software systems grow, we often encounter more challenges around organizing components, coordinating processes and managing limited resources (working around limitations).
These challenges however, are not unique to software and can be found throughout the natural world. Can we learn from studying and observing nature, and use it to build better software?
Detailed view of a dragonfly's wing membrane - Shyamli Kashyap Biomimicry
Biomimicry is the practice of applying lessons from nature to the invention of healthier, more sustainable technologies for people1.
The term combines two Greek words: bios, meaning life, and mimesis, meaning imitation. However, biomimicry is considerably more interesting than simply copying the appearance or behaviour of an organism. Its real value lies in understanding how living systems accomplish particular functions and what we can learn from their underlying mechanisms.
Biomimicry has had a considerable impact in the broader engineering field, for example, the bullet train's nose design is directly inspired by the kingfisher bird 2.
I can only speculate why biomimicry hasn't caught on more widely in software engineering, perhaps it is because developers don't like going outside (I laugh but I cry). The real reason I suspect is that there is already a huge collection of established ideas and practises, and we are often dealing with problems that have already been solved by other developers. I believe this makes it much more likely that we flock towards existing solutions in the field and compare them to our specific need and use case, and adapt where necessary. If this works, why should we bother about biomimicry at all?
To me, the value of biomimicry is not that nature necessarily provides better solutions than conventional engineering. It is that it offers a different perspective from which to approach problems. I strongly believe that being able to look at challenges through different lenses can help to build much more rigorous solutions. Additionally, nature allows us to observe systems not just in isolation, but within a much larger ecosystem. Finally, software functional requirements often change, in living systems we encounter this as well.
In summary, referring exclusively to established solutions in our own field of expertise may lead to tunnel vision and the adoption of systems and practises that match broadly, but are incompatible with our specific needs and situation. By zooming out we may discover new directions for our solutions.
Recognizing biological principles
1. Ant Colonies: Distributed Coordination
During the third year of my software engineering degree, a good friend and I developed an ant-colony simulation3. Our objective was to simulate a colony and investigate the optimal distribution of ants across different roles, including workers, soldiers and gatherers.
Figure 1. Grid cells indicate terrain type and can hold a creature, ant or colony. At the time, we approached this primarily as a simulation and optimisation problem. We wanted to understand how different population distributions influenced the performance of the colony and which distribution produced the best results under our model's assumptions.
Looking back however, I realise there was much more to learn than this.
Individual ants operate with relatively limited information about the colony as a whole, yet their interactions contribute to sophisticated collective behaviour. Rather than requiring a single individual to direct every activity, task allocation and coordination can emerge through interactions between workers and their environment.
Figure 2. The ant colony simulator rewards specific behavior by introducing traits or characteristics that positively affects the key reward indicator. A mechanism found in social insects is the use of response thresholds. Individual workers have different propensities to perform particular tasks, and their likelihood of responding can change as the demand for those tasks changes. When demand increases, more workers may become involved. When demand decreases, fewer may respond. Research has demonstrated how such mechanisms contribute to flexible task allocation and the ability of colonies to respond to changing needs 4.
This introduces an engineering question: Do we always need a central authority to decide how resources should be distributed, or can an appropriate allocation emerge through local decisions and interactions?
Imagine a system with hundreds of independent workers processing different types of jobs. A conventional approach might allocate a fixed number of workers to each task. However, what happens when demand changes? One queue may become overloaded while others remain relatively idle.
An alternative is to allow workers to respond to demand signals and dynamically adjust their responsibilities. Through local communication and individual decision-making, the system could redistribute work without requiring a central controller to dictate every assignment.
This does not mean decentralisation is always preferable. Some systems require central coordination, explicit ownership or global consistency guarantees. However, ant colonies demonstrate that complex coordination can sometimes emerge from relatively simple interactions between independent agents.
2. Homeostasis: Feedback and Self-Regulation
Homeostasis describes the processes through which living organisms maintain internal conditions within particular ranges despite changes in their internal or external environments. The human body, for example, regulates temperature and blood glucose through interconnected sensing and response mechanisms 5.
A fundamental part of this process is negative feedback. When a condition deviates from its normal range, the organism responds in a way that counteracts the deviation.
This is an interesting principle to consider when designing software systems.
Many software systems operate in environments where workloads, resource availability and operating conditions change continuously. Rather than relying exclusively on fixed configurations, we can design mechanisms that observe the current state of a system and adjust its behaviour accordingly.
We can:
- Observe the current state.
- Identify a deviation from the intended operating range.
- Respond to the deviation.
- Observe the effects of that response.
- Continue adjusting as necessary.
Homeostasis therefore encourages us to think beyond simply monitoring a system based on hard rules, instead encouraging us to think about the desired operating range, observable effects and applicable adjustments.
Applying biological principles
Let's bring what we learned into practise and see if we can actually apply what we learned!
Imagine that we are building a game where a thief is attempting to enter a manor, steal an object and escape without getting caught.
There is a guard patrolling the manor.
A straight-forward solution may look something like this:
if (player_in_vision_range) { chase_player(); } if (noise_heard) { investigate_noise(); } if (player_detected) { attack_player(); } This works, but it will quickly become cumbersome.
- What if the player walks behind the guard?
- What if the player makes noise in another room?
- What if a door is left open?
We can perfectly keep adding conditions, but you likely recognize this will lead to an influx of logic and we will end up with an increasingly complex collection of rules very specific to certain situations. And not only that, we likely will have tightly coupled the different behaviors and scenarios, as we can clearly recognize these behaviors affect each other.
So how do living organisms perceive the world? Our brains receive signals from our sensory systems. In this case information could influence the decision-making of the guard, based on what is seen or heard.
This gives us the following insights:
- We need a sensor to detect sounds in the environment.
- We need a sensor to detect movement.
- We need environmental awareness to detect changes.
Figure 3. An image from one of my personal projects illustrating an example of a physical environment that has specific properties. Strong wind, nighttime, the facing of the character, snow and ground are all various factors that affect what can be perceived.
This also naturally leads to a modular approach. A sensor's single responsibility is to sense a particular thing, and maybe relay that information somewhere. That's it!
Figure 4. The diagram illustrates the described principles through a sensor-driven input system resulting in a concrete agentic action.
We now have a clear place where we can regulate internal state in response to sensory information.
We can now choose to define ranges and limits to various senses, we can opt to accumulate these senses into an alertness amount, when the alertness reaches a specific level, or when a specific sensor exceeds the determined limit, we can immediately trigger a certain state such as search or pursue.
This offers significant advantages:
- We have a modular component-based system that allows us to refine and add sensors without having to alter anything in our detection-logic or state machine (separation of concerns, single responsibility).
- We no longer have to manually combine inputs because we do not describe scenarios and do not have a direct link between a scenario and state, instead we describe the world and provide this information to a separate process.
Figure 5. An image from one of my personal projects indicating positive and negative environmental effects on sensory input. Darkness and background noise make it harder to see, the player's vision is fixed towards the right, creating a zone where perception is easier. Darker areas make it easier for a character to hide and stay hidden.
Applied Biomimicry
Just because a particular mechanism works in nature does not mean it will work in software. Biological systems operate under their own constraints, and the same principle can introduce entirely different trade offs when applied to an engineering problem.
I believe we should approach biomimicry as a design process and methodology. In order to apply it to software engineering, we can follow a series of steps:
- Identify the engineering challenge, its requirements and constraints.
- Explore biological systems that address comparable functional challenges.
- Abstract and extract the underlying biological mechanisms.
- Translate into potential software solutions.
- Stress-test the resulting design against conventional approaches.
The goal is not to replace established practises with equivalents, but to expand the range of approaches we consider to solve a problem.
The NPC architecture example I provided is a straight-forward example of this thinking. By investigating how living organisms perceive their surroundings and respond to environmental stimuli, we can explore alternatives to state management and decision-making.
Biomimicry should give us new questions to ask and new approaches to investigate.
Conclusion
I deeply believe biomimicry has considerably more to offer software engineering than we currently make use of.
Living systems demonstrate strategies that are worth investigating far beyond their original biological context. They encourage us to reconsider familiar engineering problems and explore solutions we might not otherwise have thought of.
I do not believe every biological mechanism can be translated into useful software, But I do believe we have an enormous amount to learn by looking beyond our own discipline.
I hope you found this read enjoyable and valuable. I invite you to share your own thoughts and ideas through the comments below.
-
Biomimicry Institute. Introduction to Biomimicry. ↩
-
AskNature. High Speed Train Inspired by the Kingfisher. ↩
-
Vincent Hendriks. Ant Colony Simulator ↩
-
Robinson, E. J. H., et al. (2009). Flexible task allocation and the organization of work in ants. ↩
-
OpenStax. Biology 2e. 33.3 Homeostasis. ↩



