simplesystems.workroomprds.com
Toys
Toy 0 – a very simple system
Toy 1 – one tank, one flow
Toy 2 – bathtubs part 1 | bathtubs part 2
Deterministic chaos – Double Trouble by Dirk Brockman
Emergent order – Fireflies by Nicky Case
Puzzle
Puzzle 17
References
Thinking in Systems: A Primer, Donella Meadows
Systems and Models, Hartmut Bosel
How Complex Systems Fail, Cook
An Introduction to General Systems Thinking, Weinberg
Simple Mathematical Models With Very Complicated Dynamics, May
Simple Systems - takeaways
Two Flows
In Bathtub 0, the incoming flow is linear, and controlled by the slider (like water coming out of a tap over a bath). The outgoing flow is non-linear, dependent on the plug (plugging the flow or not) and the amount that is available to flow out (the depth of the bath).
Pathology
We're surprised because even very simple models may be dependent on rate and state – which need us to think of how responses change over time.
Trigger and observe
With the plug in, the water level rises to the top; its speed of rise is related to the speed of water coming in.
With the plug out, the slider controls the water level because the bath fills until the rate of water leaving matches the rate that it arrives, and the rate of water leaving depends on the level. Note the delay between when you set the level, and when the bathtub achieves that goal.
Resonator
The system wobbles, under some circumstances. The wobble is bigger with longer feedback, and with a more sensitive system. The wobble is faster with shorter feedback.
Pathology
We're surprised because we missed a feedback loop.
Trying to control the system by changing the wobbly thing can lead to amplified wobble or noise.
Trigger and observe
Observe over time, looking at level and throughput. Look for slight wobbles.
Amplify by increasing length of loop and sensitivity, or by reducing a damping factor.
Regulate
By damping, reducing sensitivity, reducing length of feedback
Look for 'weight' of info contained in loop outweighing info in throughput
Deterministic chaos
The system gets harder to predict the longer it runs – but remains predictable in the short-term, stays within limits, and tends to follow familiar-isa patterns.
Pathology
We prefer predictability.
'Jerk' system
Trigger and observe
Compare over time, looking at level and throughput. Look for small differences that erupt into large, variable differences – even though overall behaviour may stay the same.
There is a mathematical lower-limit of complexity; three degrees of freedom and a change in the second-order differential (I think).
These are “Jerk” systems – “jerk” describes changes in acceleration (much as acceleration describes changes in speed, and speed describes changes in position).
Regulate
By occasionally resetting, synchronising, or rounding small differences
Reduce degrees of freedom
Synchronisation
Disparate systems can synchronise, producing a behaviour for the group as a whole.
Pathology
We're surprised because we assume independence, or we assume that a loose / light connection is unlikely to lead to anything interesting.
Systems that are mostly-independent aren’t independent, but can look independent if their connections are damped down or intermittent.
Trigger and observe
Observe over time, looking at individual rates and comparing event times. Look for clusters of events arising over time. Look for generally-steady rates that change gently in one direction (i.e. not noise) and then settle.
Regulate
By damping and reducing interconnections.
By introducing small randomness to disrupt synchronisation.
Model rises to infinity
Model predicts an inexorable rise – but nothing goes up for ever
Pathology
We’ve missed a limiting factor
System dies
System stops accepting new tasks / system throughput reaches an upper limit / system shuts down, failing to complete existing jobs, and no longer accepting new jobs.
Pathology
May be related to capacity (i.e. the system can’t physically cope with more) to with race conditions / gridlock (capacity exists, but requests for resources block each other) or not releasing resources when used.
Articles and folklore commonly suggest that suggest that systems running over 80% capacity have problems. I can’t find a reasonable “systems” model for this!
Outings
Online Test Conference, 20 May 2020.
Agile on the Beach, 12 July 2018.
Rotterdam Tester meetup, 4 July 2018.
UKSTAR, 13 March 2018.
About James Lyndsay
I help organisations to find surprises, to adapt their approaches, and to keep their testers interested. I started testing in 1986, and work as an independent consultant. I've written award-winning papers, built the Black Box puzzles, kicked off the TestLab, and used to run the London Exploratory Workshop in Testing. I am a regular keynote speaker and teacher at international events, and received the 2015 European Tester Excellence award.
James Lyndsay, Workroom Productions
@workroomprds, +447904158752