Books for software engineers and managers

Thinking in Systems

Thinking in Systems

A Primer

by Donella Meadows

Engineering Manager,
Tech Lead

How strongly do I recommend Thinking in Systems?
7 / 10

Review of Thinking in Systems

Thinking in Systems provides a useful framework for thinking about the ongoing system of software construction.

Applying this book to a software engineering environment requires additional thought, but once you start understanding the concept of stocks and flows you will see practical applications each day at work.

Stocks and flows are the foundation of  systems

Take the bathtub. The tub itself represents a stock of water. Water flows in through the faucet and flows out through the drain.

In some software engineering systems we want to maximize stock, like developer knowledge within our team. If knowledge starts draining out and your bathtub runs dry, you’re going to have a bad time.

In other systems we want to minimize stock, as with customer requests. The flow to production is how we minimize lead time.

But most of the time we want to balance the stock. For instance, I don’t want an engineer on my team to feel overwhelmed and uncertain of priorities. So I’m careful. Rather than dumping the entire product roadmap on them, I selectively feed them pieces of the plan.

We sacrifice system resilience for local outcomes like stability and  productivity

Resilience often requires a whole system view, which many of us don’t have or neglect to think about.

Instead, we focus on local factors that sometimes look like resilience – factors like stability and productivity.

Being local, we can see the effect of our changes earlier. Feedback loops are tighter. Conversely, feedback loops in resilient systems often lag and sometimes only manifest themselves in extreme cases.

System boundaries only exist for discussion purposes, they do not exist in the real  world

All systems in the world interconnect. Complexity is essentially infinite.

But we need to have productive and pragmatic conversations, which require us to draw boundaries.

When we draw boundaries, we’re effectively saying, “For the purposes of this discussion…”

Framing systems as interconnected and boundaries as arbitrary human constructs can help software engineers focus on building solutions that deliver customer value. Here’s an example:

You’re building a 3rd party API integration. You diagram the system. Here’s the boundary where their system ends and ours begins.

Drawing this boundary can create both a useful but potentially problematic “us vs. them” mentality that ultimately your customer doesn’t really care about. Your customer just wants a working integration.

Look for reinforcing feedback loops that create virtuous and vicious  cycles

Reinforcing feedback loops come in two forms: virtuous cycles and vicious cycles.

Sometimes it just depends which side of the coin you’re on. Compounding interest is great for investors, not so great for debtors.

In software engineering, I focus heavily on the virtuous cycle of deploying frequently. By deploying frequently, we decrease risk and increase joy, which in turn make us want to deploy more frequently.

To find system malfunctions, identify the rule  owners

When faced with a complex system that’s not functioning correctly, look at the rules. Who controls the rules? What incentives drive their behavior?

Your perception of a malfunctioning system may drastically differ from the opinion of a rule maker.

Thinking in Systems