As engineers working in the software industry, we are often required to solve complex logic problems that take many inputs into account to determine the desired outcome. This normally takes the form of “if/then/else” logic because this is the way that software engineers have been traditionally trained to think.

If this input happens:
        perform these actions

That approach works just fine when the number of inputs is limited, but it quickly gets out of hand when the number of inputs grows. While it is certainly possible to develop “if/then/else” logic to account for a large number of inputs, that method can become hard to follow, hard to test, and hard to maintain when the conditions are more complex.

A Complex Problem

One of my passions outside of work is home automation. I have automated many aspects of my home including lighting, climate control, swimming pool controls, electric car charging, control of electrical usage based on time-of-use electric rate, security, and garage door control among others.

In the process of automating my home, one of the more complex logic problems that presented itself was how to handle the state of the floodlights in my driveway. It may sound like a simple problem at first…just turn the driveway light on! How hard could that be? Well, in my case, it was harder than it first seemed. I wanted the floodlights to behave in a certain way that took into account the time of day, the state of the two garage doors, the state of either of the two motion sensors that monitor the driveway, and the state of a button in the house where I could manually turn the lights on so they would stay on.

First, I determined that I wanted the light to be on only if it is after dusk so that the light would not come on during the day. If and only if it is after dusk and before sunrise, I want the lights to be on if any of these conditions are true:

  1. The left garage door is currently open
  2. The right garage door is currently open
  3. The left garage door has been open within the last five minutes
  4. The right garage door has been open within the last five minutes
  5. Motion detector 1 has detected movement within the last five minutes
  6. Motion detector 2 has detected movement within the last five minutes
  7. If I have manually turned the light on by pressing a button in the house

That is a total of eight different conditions (including “after dusk”) I would need to take into account simply to determine when to turn a light on and when to turn it off.

I could have turned to traditional “if/then/else” thinking to write a number of complex logic statements each time any of these conditions changes state. This is the way I started to do it, but quickly realized it would be inordinately complex and not a fun problem to solve. For example, I could have written a logic statement that does something like:

If the left garage door closes, wait 5 minutes and then turn off the floodlight, but only if the right garage door isn’t open and motion detector 1 isn’t detecting anything and motion detector 2 isn’t detecting anything and I haven’t manually turned the light on.

Lost yet? I was too.

Now, imagine having to do this for each and every condition. It would get hugely complex, and become quite difficult to maintain and debug. Fortunately, there is a far more elegant solution to solving complex logic problems such as this, and I had to look no further than my own backyard to find it.

What Can Ants Tell Us?

Everyone at some point has marveled at how colonies of ants are capable of impressively complex behavior, yet each individual ant is quite simple. Collectively ants are able to solve the complex problems of finding food, architecting and building nests, caring for their offspring, and fending off invaders. How do they do it all? Is an ant really that smart?

The answer is no. Contrary to what a popular children’s movie would have you believe, each ant is not capable of making these complex decisions by themselves. Rather, each ant is governed by a simple set of rules based on environmental conditions and signals left in the environment by other ants. Likewise, each ant is capable of leaving simple signals within their environment for other ants to find and act upon. This form of organization is called Stigmergy from the Greek root words “stigma” (mark or sign) and “ergon” (work or action).

As an example of stigmergic behavior, when an ant finds food, the ant will leave a chemical “food here” signal in the environment, will grab some food, and then will return to the nest. The ant has no idea if any other ant will find that signal nor does it care. It simply grabs some food, sets the “food here” signal, and moves on. Any other ant that detects that signal will grab some food, set the “food here” signal, and move on. Each ant is operating by very simple principles independent from and in parallel to any other ants. However, collectively they are capable of detecting and consuming large quantities of food based on following these simple rules.

Application to My Problem

In any stigmergic system, simple individual agents in the system act through indirect communication with each other through environmental factors and environmental signals based on simple rules. In the case of my home automation solution, I decided to take a cue from nature and write the driveway flood light logic using the “many simple individuals leaving and acting upon signals in their environment” concept of stigmergy.

My first step was to break down each condition into its own individual simple piece of logic (the ants). Each piece of logic would detect an environmental condition and leave a signal in the environment of my home automation system (in this case a boolean environment variable) that indicates the state of that condition. I created the following environment variables along with the pieces of logic to set them based on simple rules:

Boolean Environment Variable Value=True Value=False
After_dusk      After sunset and before sunrise After sunrise and before sunset
Left_garage_open      Left garage door is open Left garage door is closed
Left_garage_open_countdown      Left garage door was closed less
than 5 minutes ago
Left garage door has been
closed for longer than 5 minutes
Right_garage_open      Right garage door is open Right garage door is closed
Right_garage_open_countdown      Right garage door was closed less
than 5 minutes ago
Right garage door has been
closed for longer than 5 minutes
Motion_detector_1_active      Motion detector 1 has detected motion
within the last 5 minutes
Motion detector 1 has not
detected motion
within the last 5 minutes
Motion_detector_2_active      Motion detector 2 has detected motion
within the last 5 minutes
Motion detector 2 has not
detected motion
within the last 5 minutes
Floodlight_manual_on      The “Floodlight on” button inside the house
has been toggled to the
on state
The “Floodlight on” button inside the house has been toggled
to the
off state. This is also set to false at sunrise in case the
floodlight was manually left on.

Then, I created one comparatively simple piece of logic that determined when the floodlight should be on when any one of these conditions are true after dusk:

Turn the floodlight on if
   and  (

By breaking the logic down to simple individual pieces that 1) respond to very simple inputs, and 2) leave signals in their environment, I am able to create a complex set of behavior from a collection of simple actors…just like ants!

Where Else Can I Apply This?

As our users know, Dropsource is an open ended, creative tool that allows users practically infinite possibilities for creating apps. This is the inherent nature of a creative platform and is a key strength of Dropsource. As the Dropsource platform grows, the number of possibilities and combinations within the platform grows exponentially. From a test engineer’s point of view, that makes it difficult to cover each and every possibility within the product. The combinations of inputs and conditions are effectively infinite, so attempting to write tests for each possible combination would be quixotic.

That said, as a test engineer at Dropsource, it is my duty to make sure our users continue to have a top-notch, bug-free experience. So, it is a bit ironic that I have chosen inspiration from bugs to enhance the testing of our platform by applying the principles of stigmergy to the testing of Dropsource, to find bugs.

Using stigmergic concepts, we are developing collections of simple tests which, when applied in different combinations, can simulate and analyze a wide variety of scenarios while still remaining simple, understandable, and maintainable. This will allow us to continue to grow our product while still enhancing and maintaining a high level of quality.

As I mentioned in my earlier blog post “Eating Our Own Dog Food”, I am leveraging our own creative development platform to help test itself by developing some of our test tools right within Dropsource. As we continue to grow, we’ll be using these concepts learned from actual bugs to find and eliminate software bugs before they can, well, bug our users. That’s the buzz around here, anyway.