Shun The frumious Bandersnatch!

gordian knotWords mean things.  One of the more obnoxious statements of the obvious, and yet I find myself saying it more often these days.  The more I delve into understanding complexity theory, network science, and struggle to understand cognition and neuroscience, the more frustrated I get when people use terms in ways appear at odds with the literature. As I was preparing this blog to address the use of 'complex' versus 'complicated,' I found that I am certainly not alone in trying to retain some clarity of language.  Paul Jansen, in particular, has a great blog post on exactly this topic.  Nevertheless, I owe the nice people who followed this exchange on Twitter this week a brief explanation of my frumiosity.

This week, caught up in the holiday mood - I found myself engaging this week in an exchange with a gentleman, Roger Sessions, who has developed a method for IT architecture designed to 'reduce complexity.'  His paper features references to "attacking complexity" and includes a method for measuring it.  He introduces the "standard complexity unit," based on something he refers to as "Glass's Law," which posits that for every 25% increase of complexity in a problem space, there is a 100% increase in the complexity of the solution space. This reflects work from a 1979 paper by Scott Woodfield, who first posed this idea.  The idea is that increasing the complexity of problems tackled by software engineers does not increase the complexity of the solution in a linear sense, but on an exponential scale.  It is this problem that Sessions seeks to take on with his approach.

Now the notion of reduced complexity is attractive, if you understand complexity as a system that has developed so many connections as to become unmanageable. This is a common usage for 'complex,' which seems to translate to "something too hard to understand or manage or control or cost."  The notion of 'wicked problems' applies here as well.  The greater the connections you find among things, the greater are your odds of decision paralysis and "failure."  Solution?  Easy, make things simple.  The danger, for me, comes in simplifying management behaviors in ways that deny the nature of the systems we are attempting to manage.  If you believe complex is nothing more than the 'opposite of simple,' you are missing some of the most promising areas of applied research in a half century.

When I engaged the gentleman on his use of the term complexity, I received what I believed was an odd response.  For someone who uses the word in titling his books and lectures, he did not appear terribly connected to the word itself.  He even invited me to suggest a different term for what he was trying to achieve. The closest I could come to his definition for complexity (admittedly, without buying his book) is an 'exponential growth in system states with regards to information technology systems.'  To me, he is trying to help people with an architectural approach that makes overly-complicated IT systems more manageable.

For his part, Roger was comfortable with my discomfort, because in his world "complex" merely means the opposite of "simple."  Several of us during this Twitter-fuffle suggested the use of "complicated," which suggests a system that has known but prolific connections.  Cause and effect in complicated systems are related and knowable, but analysis by an expert will likely be needed to connect them when something goes wrong.  My example here is the 'check engine light' on my car - while I am at a loss to understand the cause, an expert with tools can ascertain it quickly.  Modern car engines are extremely complicated.

They are not, however, complex.  My car engine is unlikely to evolve new features anytime soon.  There is a reason medical doctors have different training regimes than auto mechanics.  The latter deal with complicated systems, the former with complex ones.

Complexity is a specific term.  Complexity, as described in the literature, is a science that seeks to explain how emergent order (often called 'hidden order' or 'self-organization') is observed in systems or (most) networks. For what it's worth, I believe those seeking to develop IT architectures could benefit from a deep understanding of complexity, as their users are sloppy humans in messy and evolving sub- and extra-organizational work networks.  Methods for complex systems management show some promise in 'attacking' the unmanageable IT systems that Mr. Sessions is tackling here.  It may be that observing and nourishing self-organization among human-based networks, rather than embedding and enforcing an existing or desired organization within them, will help architects develop more manageable and relevant IT systems.

As a blog post, however, this has gone on long enough.  I just wanted to explain my bristling at a usage of the term 'complex' in a way that conflicts with the literature. At one point, Roger reminded me that he is trying to tackle an extremely serious problem.  I respect that, of course, and was doing the same.  Given the great work that is ongoing around complexity and complex adaptive systems, we owe some respect to giants upon whose shoulders we seek to stand.