You can get the benefits of emergent behavior and mitigate errant behaviour if you have good visibility of the overall system and if what you see is intuitive in human terms (thus visualisation and HCI/UX) .. going back to the cell model: simple rules of cells at the micro level can create complex macro-level behaviour, but it's not scary if it results in fun, playing the game of life, or growing a plant.. Again, visibility of state is the most important thing.

In games, emergent behavior is amazing and the rise of systemic games shows that the masses think so too. 🙂 Emergent behavior in your 911 system might not be so desirable though.

but any system with multiple parts interacting asynchronously will have emergent behaviour, especially with humans in the loop - emergency systems included!

haha

simple rules or not

That gets to the real question in my mind: how do you specify systems in such a way that the behavior you get is going to be in the positive class as opposed to the negative class. You can't control the world, but you might be able to meaningfully funnel it 🙂

Well like I said, I believe that's down to intuitivity and visibility, in human cognition terms (not in terms we autistic spectrum techie types usually gravitate towards, if we want to empower "normals"!)

We just need to encode general search, "do these rules have any weird consequences?"

Jim Coplien makes an interesting case against emergence in "Reflections on Reflection" (from 21:40 - 25:40): https://www.infoq.com/presentations/Reflection-OOP-Social However, I think he's specifically talking about a common "emergent" programming style (often employed in "OO" programming) where the known & expected behaviors of the system "emerge" out of the data model (e.g. each object or class gets a "slice" of the overall system behavior). That kind of emergence is bad, and makes code much more complex and unpredictable than necessary. So I think it's a matter of deciding / understanding where emergence is great, and where it is not (e.g. growable systems vs. the concrete specifications within individual programs).

That gets to the real question in my mind: how do you specify systems in such a way that the behavior you get is going to be in the positive class as opposed to the negative class. You can't control the world, but you might be able to meaningfully funnel it

@ibdknox I think the solution to this is to structure the system not around explicit limitations but around smaller-scoped quid-pro-quo contracts, and to limit UB within contracts but not between them. One of the problems with the current generation of digital systems is that they severely limit flexibility. The supposed benefit of these systems over say paper ones is an increase in data integrity, but it doesn't necessarily have that effect. For example, suppose we have paper forms for people who are taken into police custody, and this form has a "DOB" field. Officers might reasonably want to write into this field things like "1970", "Claims 2005 but clearly older", "1st March, 1969 or 1968 (too drunk can't remember)" etc etc. If this form is digitized, then the DOB field might reasonably be made to be a Date picker. Now, not only can none of these be entered, but what's more we might be coerced into entering invalid data like "01/01/1970" instead of "1970"! However, obviously there were reasons to ask for the DOB to be a valid date. It let's us do powerful things like query all people born within a specific range. It let's us reason more easily around the rest of the system because we can make valid assumptions. However it's wrong to think that this more restrictive design is definitely "safer" - this is just arrogance on the part of the people at the time of design, thinking they definitely know better than future users. Systems like this should be designed more along the lines of; 1. I want a date of the form 01/01/1970, and I will let you know if you don't give me that 2. IF you give me that, THEN I can perform this other action 3. Otherwise, I can't help you I think this is why Unix tools are so heavily in the "good" side of emergent behaviour. Each one is simple, has an easy to understand contract, and individually has no undefined behaviour. Together they can create fantastic things in unexpected ways. The same is true (in a way) of LEGO. Disaster strikes when a tower of assumptions is built up and then changed somewhere in the distance. Keep assumptions local and explicit and this should be avoided.