It’s a trap!

I recently read a great article about traps in software development
The post itself was summarising ‘System Thinking – A Primer’ by Dana Meadows.
And to help it sink in, I’m going to summarise the summary here.

A trap is roughly defined as a system structure that tends to result in problematic behaviour.
In my own vernacular, I’d probably call it a process that doesn’t help us fall into the Pit of Success

Policy Resistance

Occurs when there are conflicting needs between multiple parties in a system.
It’s a tug of war, and the harder you pull the harder the other party pulls back.
You’re never going to get anywhere, but you’re going to expend a lot of energy doing it.

Tragedy of the commons

Caused by misplaced, often short-term, incentives leading to sub-optimal long term results.
E.g. fishermen are incentivised to over-fish, depleting stocks and destroying their own livelihood.
E.g. constantly adding new features at the expense of a maintainable codebase.

Drift to low performance

When we base our projections on perceived current state rather than an objective reality or pragmatic ideal…
… Goals can erode over time leading to a downward spiral.
E.g. code perceived as bad can lead to maintenance efforts being “just good enough”, further lowering its quality.

Escalation

An arms race due to the perceived state of a competitive system – the opposite of ‘drift to low performance’.
Often occurs when competition is misguidedly used as a motivator.
What happens when we’re all measured against some proxy? The measurements will improve, that’s what!

Success to the successful

The rich get richer while the poor stay poor.
Becomes more important to appear to be successful than to actually be successful.
Can stifle innovation due to fear of the repercussions of failure.

Shifting the burden to the intervenor

When the solution to a problem undermines the capacity of the system to maintain itself.
E.g. solving an alcohol addiction by having another drink, it certainly helps (in the short term).
E.g. bug fixing by patching over the symptom, leaving the underlying cause un-addressed.

Rule beating

When rules cause a system to behave in a distorted way, nonsensical in the absence of the rules.
Often due to following the letter rather than the spirit of a law.
E.g. lengthy sign-off required for projects estimated over X… most work becomes estimated at X-1.

Seeking the wrong goal

You have a problem with rule beating when you find something stupid happening because its a way around the rule. You have a problem of wrong goals when you find something stupid happening “because it’s the rule”. ~Dana Meadows

Often occurs when progress towards a goal is evaluated via a proxy measure rather than the goal itself.
When the proxy measure becomes the goal itself.
E.g. King Midas sought the wrong goal – turning everything you touch into gold doesn’t necessarily make you rich.