Thinking In Systems A Quick Review of Thinking in Systems by Donella H. Meadows and Diana Wright

I was first introduced to this book in my “Intellectual Foundations of Informatics” class. While we were assigned an excerpt from one of the first few chapters, I quickly realized I wanted to revisit this book in its entirety. Rarely, if ever, have I been assigned class reading interesting enough to want to go back in my free time to read the book cover-to-cover.

This book was my introduction to the concept of systems thinking, and I came to realize that systems thinking peaks my curiosity in the same way that building something does. Taking code (or parts and pieces of something) and building something greater than the sum of individual parts and pieces is addicting. Learning how to take complex systems and analyze them through a reductionist approach can help you diagnose and troubleshoot everyday problems. At the end of the day, society is a system, and everything we do contributes to it as inputs and outputs. If we have a shared framework for describing and analyzing systems, we are more likely to successfully diagnose issues in the system and prescribe long term fixes.

As much as I want to start ranting about the big problems in society, the goal of this blog post is to introduce the concept of systems thinking to a technical audience.

What follows is a very brief introduction to systems thinking using an example that might interest a software developer. After introducing some fundamental concepts of systems thinking, I explain one of my favorite (and in my opinion, the most important) lessons from the book “Thinking in Systems” by Donella H. Meadows and Diana Wright.

Like tax policy, traffic, and drug addiction, technology and software systems can be described through the concept of stocks and flows. To really understand that claim, I highly recommend picking up a copy of the book for yourself. The definition of a stock is almost too simple to define: The current state, level, or “memory” of something as influenced by flows. Yes – the term something is awfully vague, but that’s because the concept can be applied so broadly. It can mean everything from users of a software system to water in a lake. Flows are the actions and changes occurring in the system that influence a stock. Using similar examples, a flow can be user sign-ups on a website, or beavers damming up an outflow of a pond.

Given these basic definitions, let’s narrow in on our example of a website. Let’s use a social media website/algorithm as the system of focus. There are endless ways to slice up this system, however here is a quick take:

• Users not on the website
• Users engaging on the website
• User Content

• Sharing a post/photo
• Liking a post/photo
• Notifications

Expanding on that further, here are some examples of how those stocks and flows interact with each other to form a system. There is a stock of users not using or engaging with the social media application, and there is a stock of users who are currently engaged on the site. As users share and like posts, (the “flow”) is causing an increase in content. The algorithm, as designed, will produce notifications (also a “flow”) that are sent off to both stocks of users. The result? The stock of users who were not on the website might decide to interact with the notifications, converting those users into actively using the site. In effect, those notifications are increasing the stock of users that are engaged on the website.

As users are engaged with the website, liking and sharing content, they increase the stock of new content. This new content acts as a buffer (a stock of user content) for sending out more notifications. The result of all of this data/information flow? A feedback loop for keeping the stock of actively engaged users high. It becomes immediately obvious why users and user engagement are the most important metrics for a social media company. The more you have, the more likely you can get more.

This was a quick and dirty example showcasing how we can break up systems to analyze how they work. No matter what problem you are trying to solve with software, modeling that system through the eyes of a system thinker might help you uncover new relationships within a system. Even if they don’t uncover new findings for you, it can still be an effective way to describe/document what you know to your peers.

One of the most important lessons I learned through this book is that when modeling a system, that model is never complete – and never will be.

1. You can keep on zooming in on the system to find details that weren’t modeled in enough detail.
   • Example: Analyzing the impact that garbage collection will have on your system likely isn’t the first performance optimization you look at when deciding on how to process a large data set. Never-the-less, it still factors into the end system.
2. You can zoom out on the system (or hit refresh) to find new inputs/outputs of the system that weren’t ever modeled or considered.
   • Example: When WD-40 was created for water displacement in rockets, they weren’t planning a sizeable chunk of business to come from customers wanting an “all-purpose lubricant” for use in their garage.

At the end of the day, systems modeling provides a framework to analyze how a system behaves. Just because we can perform systems modeling, doesn’t mean that we have the complete picture. Systems modeling and thinking is not a means to an end, but a tool that can be leveraged to communicate and think through complex problems. It is a useful tool that can be used to communicate how a system operates and changes. I highly recommend picking up a copy of this book for yourself.