Originally I was writing an article about several systems to keep your Makers (product, engineering, design) team happy and productive. But I ended up writing too much to fit in one article so here is the start of this new series.
Today, I want to tell you about one of my favorite fields in computer science: Multi-Agent System. I want to tell you about Emergent Behavior and how this can be used to foster a happy and productive work environment. This is also the opportunity for me to merge some of my favorite fields: multi-agent systems, emergent behavior, and enterprise architecture.
A Multi-agent system, in computer science, is a simulation where multiple “agents” are interacting with each other and with the environment. There are two kinds of agents: passive and active.
An active agent is an entity that executes code and can potentially move and interact with the environment. It can be called a “turtle” or an “actor” in some simulations. To draw a parallel with real-life: it could be an ant or a termite part of their colony, or an animal part of an ecosystem, or people part of a city. During a simulation, the status of the agents will be monitored, for instance, what is the average “hunger”, or how many are still active. The code embed in the active agents will be related to how they move, what they perceive and what resources they consume.
A passive agent is an element of the environment. It can be a source of energy that active agents will consume, for instance, “grass” that “sheep” could eat. It can also be a "wall" that will impeach the movement of the actors. Usually, the code for this agent will be related to their reproduction rate (for instance, how many blocks of "grass" appear every second).
When the simulation is running, each agent will execute its own code in parallel with the other agents, they are independent of each other. This implies a decentralized system, no entity in the system knows about the entire environment. And finally, each agent can only know about its surroundings, no agent knows about the full system.
The best simulation software, to play with multi-agent systems, is calledNetLogo. It allows you to run example models provided by the software as well as writing your own systems. Back when I was a student, I wrote a lot of models andshared a few on the community platform. You can also see on this platform that a lot of models related to Covid19 propagation have been shared. One of the most viewed models, at the time I write this article, is asimulation of the spread of the Covid19 from Nich Marting. You can go to the “Run in NetLogo Web” tab on your desktop browser to run the simulation for yourself.
On this platform, you can also find one of the most basic and famous models:Wolf Sheep Predationwhich you can run for yourself and try to findequilibrium. If you don't tweak the parameters right, you can end up with a situation where wolves reproduce too quickly, eat all the sheep and die of hunger. When the parameters are right, the grass, sheep, and wolves population are stable over time.
With the rise of IoT, the researches in the field of Multi-Agent Systems have multiplied. You can read, for instance, about how multi-agent systems technology is used to optimize electric grids inthis paper. Or in this paper onCooperative Multi-Agent learning: how agents can cooperate to solve problems.
This brings us to the next topic:Emergent Behavior.
In a multi-agent system simulation, each agent's code is extremely simple. The large number of agents and the time passing can sometimes create what is called Emergent Behavior. The idea is the accumulation of simple actions can create complex behaviors.
I like to say: “Simple rules, big consequences”.
We encounter this phenomenon all around us all the time: from our cells forming organs and ants forming colonies, and us, Humans, forming cities and enterprises. All those examples are complex autonomous systems made of simpler parts.
Re-using what we have learned in the previous chapter on multi-agent systems, we can use Netlogo to simulate this kind of system.
Here is a simple example. In this scenario, the Active Agents are Termite, the Passive Agent are pieces of wood. The only code that the Active Agents have to execute is as follow:
- If you find wood and you don't carry anything, put wood on your back
- If you find wood and you carry something, put the piece of wood you carry next to the one on the ground
- Otherwise, more randomly
That's it. You would expect the result to just be a shuffle of pieces of wood moving randomly from one place to the next because of the random movement of the termite. But after enough time, the result is one perfectly circular stack of wood. This is an Emergent Behavior, nowhere in the code, there is mention of a circle or of a position where the circle should be. As a matter of fact, each run will produce a circular stack at a different location. You can go to the community platform of NetLogo to watch theTermites in action for yourself.
To learn more about Emerging Behavior I would recommend watching this youtube video titledEmergence from Kurzgesagt if you don't watch the video, here is my favorite quote from it: “complexity arising from simplicity”.
Before talking about how we can implement brilliant rules in the workplace to produce great emergent behavior we need to talk about us, humans.
Let's not forget that we are all agents of our cities. We are also all agents on the internet. We are agents on the stock market. The simulation is already running, us being aware of it or not. But we are not simulated agents in a sterile simulated environment. Each individual is unique, with their own set of code and rules that they follow, their own set of needs and requirements that need to be met as well as personal goals to achieve. To go back to our simulated environment, it is like each of the agents already had a lot of code written that we cannot change, or read. This makes it more difficult to implement new rules but not impossible.
Image of Us as agent of our cities from the YouTube video "Emergence by Kurzgesagt":
One important thing to understand is incentives. We all carve a path from where we are today to where we want to be. This can be imagined as a river flowing. This flow is the incentive that each person is driven by. When implementing new processes in an organization, it is important to be aware of each person's river flowing and which direction they go. The goal of a leader is to bring all those rivers to flow together in the same direction. One way would be to force people to do it, but that obviously does not work: putting a wall against the flow of a river will just destroy this wall rather than redirecting the river. As a leader, we need to find incentives and simple processes that will curve the flow of the river while keeping everyone happy and fulfilled. Keep the flow of the river in mind as we jump to the last part of this article.
Now we know what is a multi-agent system and we know that a system with carefully crafted rules can produce emergent behavior that will make it greater than the sum of its parts. We also know that we are all Agents driven by incentives.
So far, we mostly talked about emergent behavior that produces positive outcomes. But it is important to realize that it is very easy to trigger negative emergent behavior when not careful.
For instance, setting up a development process where the Product Manager and the Designer spend time building the new feature before handing it over to the engineering team seems like a great idea at first. This will earn you some extra engineering time since they are not part of the meetings and can just focus on writing code, right? Yes, but… One incentive that engineers hold dearly is to solve challenges, solving puzzles is usually why passionate engineers become engineers in the first place. Trying to save some engineering time, this simple change will make some engineers dis-engaged, they will lose motivation to work, productivity will drop and ultimately either they will leave the company or they will be fired because the productivity metrics would not be met anymore.Simple rule, big consequences. A solution is to involve the engineers that want to be involved in the design process.
Another example, as a tech leader we want consistent code over the organization, it makes it easier for engineers to switch teams and it makes the code easier to maintain and read. Let's implement these new rules: the line must not be longer than 100 characters, there must be spaces after commas, constant must start with an uppercase letter, etc… Lots of companies have those coding rules. The emerging behavior will be that most code reviews will now obsessively focus on code style rather than functionality. Some engineers will spend hours back and forth arguing about spacing and mistakes forgotten. The functionality of the code will become secondary. Those back and forth exchanges, especially in a remote environment, will create more tension between engineers and hurt teamwork. Ultimately, a toxic environment would have been created.Simple rule, big consequences. A solution is to automate code styling rules as much as possible so employees don't have to think in order to follow them. If any code styling practice cannot be automated, forget about them.
It is possible to put in placecarefully crafted insignificant-looking rulesthat together create Emergent Behaviors. Instead of enforcing a behavior you desire and make people unhappy about having to follow complex rules and processes, try to study the system of incentives. Studying what people want and putting simple rules in place will be a lot more effective at accomplishing what you want.
For instance, during the pandemic, a lot of people complained about burnout. People are social creatures. Let's say you block all meetings in your company during lunchtime, this is a simple rule. Several Emergent Behaviors can come out of this simple decision, for example, people that live alone might organize lunch and learn to spend time together or, others might spend more time with their family.Overall, your workforce will be happier and more productive.
Here is another example of generated positive behavior. Implement code pairing sessions, this is when two or more engineers are using one computer to write code together. Sure, you might think at first that it is a waste of engineering paid time, why pay 2 engineers to do the job of one. But implementing those sessions will trigger exchange of ideas and good practices among your Makers staff. They will teach each other tips and tricks on how tobe more productive. Another side effect is that the code review time will be shorter since already two brains have looked at the code while it was written.
If you need help setting up simple processes, that fit within the culture and values of your enterprise, to keep your Makers team happy, fulfilled, and productive: reach out toPURE LAMBDA.