Basic Pathologies of
Simple Systems


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 17


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).


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.


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.


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.


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.


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).


By occasionally resetting, synchronising, or rounding small differences

Reduce degrees of freedom


Disparate systems can synchronise, producing a behaviour for the group as a whole.


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.


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


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.


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!


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