Complexity In Context – Complexity vs Systems Thinking

This is the 3rd in a series of posts drawing out the ideas in Dave Snowden’s State Of The Net 2013 Keynote “How Not to Manage Complexity” in an attempt to get my head around complexity. Today I look at…

Complexity vs Systems Thinking

Both Complexity & Systems Thinking are new to me. That said, I don’t for 1 second believe I can cover the differences between Complexity & Systems Thinking in one post…

These are some ideas from Dave that piqued my interest, some of which of which conflict with I thought I knew. Bear with me in this section…

 

Working towards a future state

The idea about the future state we work towards apparently differs between Complexity & Systems Thinking (introduced at 13:00 minutes)

In System Thinking, we define an ideal future state and attempt to close the gap.

In Complexity Thinking, however, we accurately define the present and through safe-to-fail experimentation we evolve to a more sustainable & resilient state. This experimentation is made possible by identifying the things in the present that we can change and then monitoring the effect of those changes (more on safe-to-fail experiments in another post).

In complexity, we cannot predict the future and as such we need to manage in the present to guide us to a future that is more suitable for us.

It’s application to software development

In my previous post on Cynefin in Software Testing, I discussed the idea that software development (particularly in the early stages of a project) is complex.

My experience of software development projects has typically involved requirements provided up front – the problem has been identified & analysed and a  potential solution has been put forward for us to build. The ideal future state has been defined (a la Systems Thinking).

Past experience (& evidence outside of my experience) has demonstrated that defining the future state & closing the gap perhaps isn’t the best way to develop & deliver software. Either the future state keeps changing or the gap (typically) widens as we discover new information about the project.

I haven’t been on many projects where the ideal future state hasn’t been defined so I don’t have the experience to comment on ideas in Complexity Thinking around accurately defining & managing the present and evolving to a more desired future state. I am learning about these ideas & performing my own experiments in order to try them out in a real project.

 

Breaking down the System

In complex systems, we need to see the system as a whole (idea introduced at 12:00 minutes). The complex system is not reductionist nor aggregative so it cannot be broken down and managed in parts.

Breaking down a problem into small parts in order to fix the small parts & then build those parts back up only works in the ordered domain (Complicated & Obvious).

This flies in the face of what I thought was true – break down complex problems into their parts in order to simplify the problem. At work (and in school) this was typically the approach we were advised to take.

I’m now wondering if it’s my understanding of the definition of complexity that’s confusing me.

In school, the problems were unlikely complex (according to my understanding of Dave’s presentations) as they actually had a solution. This would make them complicated and as such they could actually be broken down into parts. I’m now thinking about more concrete examples from work…

 

Drivers vs Modulators

Systems Thinking has “Drivers” whereas the Complexity Thinking has “Modulators” (introduced at 10:50 minutes). Dave talks about this difference in his own words over on Cognitive Edge

To be honest, I haven’t got my head around this idea. This is where I’m at so far.

The term Driver implies something is driving something else, which in turn suggests linear & predictable change in the thing being driven. For example, if the engine is running in my car, when I press the accelerator pedal then the engine revs. This is a complicated system.

In complex systems however, there are more than 1 to 1 interactions. It is hard to discern what is being driven by what as there are too many factors changing at once. Think about all the factors that have an impact on your mood by the time you reach work; early/late to bed? Good/bad nights sleep? No milk for your tea? Bad traffic? Crash on the motorway? Waiting for the lifts up to your floor…

It’s application to software development

Once again, software development can be complex. With many factors impacting the behaviour of the software & a large number of these factor invisible to those of us developing it, it is hard for us to discern what is being driven by what. Instead of focussing on the drivers, linear causality & predicting the future we should explore what factors could be varying the software’s behaviour right now to help us understand what our next move should be.

I expect this section will change the most as my understanding increases.

This article on 5 differences between complexity & systems thinking is getting a good reading. multiple times.