Thinking about it, I'm trying to show people an example of something that couldn't be understood easily. Even worse: their inability to understand my example, to get an experience to feel themselves overwhelmed by a complexity, is a goal of mine. It feels like a self-defeating goal, it has a self-contradictory feeling.
So the question is: had you succeeded explaining people that there are things so complex, that their complexity couldn't be managed regardless of amount of resources one might put into management? If you had, how you did it? Is it even possible without spending few hours speaking passionately?
For example "What if two programs did this?":
https://devblogs.microsoft.com/oldnewthing/20050607-00/?p=35...
Often people with a poor grasp of complex systems will make a naive suggestion like "if x fails, we can retry n times". In isolation, this makes sense, although it adds complexity. In the grand scheme of things, it doesn't make sense, because if x does y, and y has a failure and retries... and then y does z, and z has an failure and retries, well now you have x * y * z retries all multiplying out and you won't hit your top-level "n times" restriction until after the heat death of the universe.
With a bit of practice, you can spot and point out these kinds of things.
https://en.wikipedia.org/wiki/John_Boyd_%28military_strategi...
See also, for a mathematical definition and proof, Kolmogorov complexity
https://en.wikipedia.org/wiki/Kolmogorov_complexity
Re the good and bad of late ancient Roman attempts to manage complexity and disorder see Gibbon, etc. Standardization within the army, and garrisoning all cities with permanent localized troops to discourage rebellions by frontier generals. Gibbon sees the latter as the beginning of the end, since most of Rome's military power was now employed in the task of internal stabilization and couldn't be used against the barbarians.
And as a side note, when in conversations I notice we use abstract words to hide complexity, for example normal people say "I had a bad digestion", but if two doctors were talking they would probably get pass the digestion word and get into the details of the complexity, and maybe end up talking about the lack of encimes and questioning if there is a problem in the organ that produces them.
Alas, the main obstacle is this: you actually want to teach how simple rules create a system (complex or not, doesn't matter, but a system). Well, a non-programmer has a difficulty mentally "running the instructions step by step" correctly as a CPU would do. You can give them some really simple mechanistic orders and watch them miserably fail after a few iterations; they usually anthropomorphize the entities, assigning to them intentions or emotions which by definition cannot be present.
Since they cannot approach from the side of simplicity, any complex system becomes impenetrable and they apply general heuristics to deal with that, which you would like to prevent. No idea how to help you.
As a software tester I would suggest just that- build together kind of a test plan, slowly add layers to it and while doing it demonstrate bugs that were find in different places.
Even the simplest web site can result in huge number of tests if you go low level enough, networking, servers, disks, backups etc.
Or weather...
Sometimes this mismatch is intractable or irresolute. Rather than looking for specific examples of complexity, if people are being glib about how "easy" complex systems are to "solve", you can bring up Wicked Problems, which tend to be about the state of complex systems.
https://en.wikipedia.org/wiki/Wicked_problem
The field of Failure Studies tends to be about complex systems. The book "Drift Into Failure" specifically talks about how our default mechanistic interpretations of systems tends to mislead us into believing things fail for singular, spectacular, and simple reasons, when in many large-scale systems they fail through a compounding of innocuous events.