If you walk into a bookstore you will find books on saving yourself, but not on saving the world. You will find books addressing specific problems, but not on how all these problems relate together as a whole. There are a few books like that of course. I have made a point of finding them. But they are not well known and definitely not best sellers. Why is that? Why don’t we have even one well known plan to save the world? Partly because it is just too overwhelming. We are all stuck in the trance of helplessness. Our shared story is still way too small. But another part is that most of us don’t have much experience working with complex systems. Some people do though – for example programmers. We have to. No one ever formally taught me how to manage complex systems, but out of necessity I learned it over time. I learned that any problem at its heart is because people are far from perfect and you have to figure out how to compensate for our human weaknesses. It turns out that is true of all our problems, not just computer ones. Later on I discovered there is a name for this kind of thinking. It is called Systems Thinking. It recognizes that when you are dealing with the “wicked problems” of the world you first have to understand the whole system. The temptation is to just pick a part of the problem and get to work because the need is so urgent, but that ultimately has limits. It can help, but it will not get us all the way where we want. We need to go deeper. We need to use systems thinking. It is the only thing that works. So how does this method work? Let me give some examples.
I truly hate getting woken up at 3am to solve a service outage. I especially don’t like having to report to senior management why I personally cost the company many hundreds of thousands of dollars in lost revenue. And yet this has happened to me. So I am highly motivated after each incident to learn from it what we can do to reduce the chance of it happening again. At my company whenever a bad outage happens we initiate an inquiry process called “The Five Whys”. This process simply asks “why” five times, but each time the “why” is at a deeper level. We first look at the very topmost “why”. Why did we have the outage? Maybe the database stopped working which cascaded into the whole system going down. OK, straightforward enough, but then we ask “why” again. Maybe a single server in the database went down and automatic failover was not set up. Getting a little deeper now, but again we ask “why”. Why did we miss turning on auto failover? It turns out no one thought to test what happens when just one database server goes down. Now we are deeper yet, but again we ask “why”. Why did we not do the testing? Maybe we did not have a properly thought out testing plan. Getting close now, but there is still another “why” to ask. Why did we not have a proper test plan? It turns out that many software developers like myself are secretly loathe to do proper testing. It is hard enough to get the dumb thing working, and we unconsciously resist deliberately breaking our beautiful software. So we suck at testing. But it turns out there are some pathological individuals (testers) who actually love to break software. They delight in it. Put those guys in charge of the testing plan and everything runs much smoother.
Do you see how each “why” brings us to a deeper level? When we get deep enough we can get to the heart of the problem, and that is where we can make the real fix. If we just said, “Oops, didn’t set up the database correctly!” we don’t solve the real problem. And the next time we release a new program that yet again has not been properly tested we will yet again get woken up at 3am. Get woken up enough times and eventually programmers learn to look at things in a deeper way. Again, it is the only thing that works. There is no magic in the number five. Sometimes you can get there with fewer than five whys; sometimes you need more. This kind of thinking is so necessary when working with complex systems. But it doesn’t look like most people are aware of it yet. Let me next give a real world example.
During the Trump presidency it felt like political commentators were crashing around their bedroom at night trying to get to the bathroom. Blind to what they were stumbling into over and over. Many focused too much on Trump without realizing he just represented the yearning of a huge number of Americans. Many others viewed his movement as a uniquely American problem, and failed to see that there has been an absolute plague of authoritarian governments in the world recently. Others only focused on recent events without realizing that this is an age old problem. And even more failed to recognize that this authoritarian mindset has been with us from the very beginnings of recorded history. It turns out that it is rare for a democracy to not succumb to authoritarian collapse at some point. We need to stop and take the time to turn on the light and see where we are. What exactly are we bumping into? We see this authoritarian mindset, are there other mindsets that are also driving the world? We need a map. If we truly want to succeed in winning hearts and minds we need to meet people where they actually are, not where we think they should be. In my experience telling people that they are crazy and evil just has not been an effective way to get them to change. Have you had a different experience? This is where theory and models can help. We need a better understanding of why people do what they do.
Why did I decide to create a web site instead of writing a book? Systems thinking. Books are written primarily by one person and then sent off into the capitalist marketplace as a finished product. That is not what we need here. That is working at the wrong level. We instead need a living document that can grow and change. And I need a system that accounts for my weaknesses and ignorance. Fortunately, one thing I have had to get good at as an engineer is admitting that I am wrong. That I made a mistake, sometimes a very big one. To this day there is a sting to it, but after all these years this sting is very familiar to me. And especially on new projects it is quite often necessary to change your mind on major parts of the project. Oddly, I think that this engineering mindset can serve well here. I am proposing a very new, big plan. I’m pulling from well established wisdom traditions, but quite probably the way I am pulling them together is going to need a lot of review. Software engineers know a lot about how to work with a situation like this. Projects like this get better and better the more eyes you put on it. And the best way to harness that phenomenon? Open Source.