Complex vs Complicated
Introduction
Leave it to the English to have the most words of any language, but to give us words that still leave us scratching our heads on when to use each. This would be the case when it comes to “tough to manage” systems. We have words for these tough system, but few people know the difference between “Complex and Complicated”. We don’t need more words - we need different words.
The words we have feel too similar and thus the nuance they attempt to explain are lost in the wash. Each word is trying to assess different things, but since the context is not distinct enough they continued to be used interchangeably.
Complicated has to do with difficulty.
Complexity has to do with reproducibility or predictability.
The distinction is significant and worthwhile for organizations looking to use Machine Learning or Adaptive Systems.
Alternative Definitions:
Simple = easily knowable.
Complicated = not simple, but still knowable.
Complex = not fully knowable, but reasonably predictable.
Chaotic = neither knowable nor predictable.
Said differently:
Complicated generally means a high degree of _____ but given a set of inputs you can follow the intended behavior and have good certainty about what a system will do.
Complex means that there is often a similarly high degree of _____ but given a set of inputs, the outcome is intrinsically unknowable. If a system evolves based on its past history - and potentially working in conjunction with other systems that carry an evolving nature with them - their singular outputs are complex and then certainly their joint outputs even more complex.
Complex = systems made up of decentralized agent parts that have individualized objectives but have an emergent behavior
Dealing with complexity is about adapting, reacting, dealing with conflict, continual improvement
Using policies conceived in complicated environments - are fatally flawed when confronted with the organic and evolving nature of a complex system.
Stack Overflow will not solve this because the general population is equally confused.
To illustrate the differences, some examples.
Simple problems, such as following a recipe or set of instructions, may encompass basic issues of technique and terminology, but once these are mastered, following the ‘recipe’ carries with it a very high assurance of success.
Complicated problems (like sending a rocket to the moon), are different. Their complicated nature is often related not only to the scale of the problem but also to their increased requirements around coordination or specialized expertise. However, rockets are similar to each other and because of this following one success, there can be a relatively high degree of certainty of outcome repetition.
A traditional web app, for example, can be very complicated. It has web servers, data stores, CDNs, caches, asset build processes, deployment processes, source control systems, and more. At any point in time, any component in that list may be “totally busted” and causing the whole thing to crash. Or consider older applications with external consumers that tend to have “legacy” components (translation: parts that no one wants to touch - and if forced to do so - will complain endlessly about how bad it is and how dangerous changes are to this area of the system). Each version of the application has an interface that was let lose to paying customers and, for example, this application had the fatal problem of “successful” customer on each versioned interface.
This application starts to become very heavy and improvements to the current version may have negative impacts for an older version. Nonetheless, with significant engineering work and process controls - this system can grow with reproducibly positive changes.
In contrast complex systems are based on relationships, and their properties of self-organisation, interconnections, and evolution. Research into complex systems demonstrates that they cannot be understood solely by simple or complicated approaches to evidence, policy, planning, and management. Consider complex systems like raising a child. Formulaic approaches have limited application.
Raising one child provides experience but no assurance of success with the next. Expertise can contribute but is neither necessary nor sufficient to assure success. Every child is unique and must be understood as an individual. A number of interventions can be expected to fail as a matter of course. The uncertainty of the outcome remains. The most useful solutions usually emerge from discussions within the wider family and involve values.
With a technology-based example, consider a recommendation engine. It has application logic, CDN for assets, datastore, etc - basically all the same stuff as the web app. However, once you program the recommendation engine you actually can not guarantee that it will recommend the same thing twice, assuming the dataset is evolving over time. So what does it mean to get the “expected outcome”? What was the expected outcome? Consider the fact that it was not created with an expected outcome. It was created to pattern match. Watch what people tend to look at next - and over time recommend that pattern to other people. What if your first few people moving through the content were weirdos? Now you recommendation engine seems very bad. This is complexity. 1
¶Misconceptions
How to deal with different systems/organizations
- Top Down Planning vs Changing Objective Functions
¶Misconception: Complicated is Complex
If you were to plot complicated on the Y-axis and complexity on the other axis you can have two different systems at the top left, and bottom right. These two words are at least conceptually unrelated. But this fact is easy to overlook when you are knee-deep in the thick of hard engineering problems to put a rocket on the moon. To relate it back to the prior idea, if the recipe has some parts that are not precise enough - it matters greatly “who does the pinch of salt”. That part leads to uncertain reproducibility. This often happens when a company is producing product at a rate that exceeds the organization’s ability to understand the interdependencies.
Rephrased the question is: As things get more complicated - do they tend to get more complex? Answer: It depends on the rate an organization uses shortcuts that introduce wiggle room which often fails to constrain a process to give an expected outcome. So if you feel like the answer is yes, you have just learned that your teams tend to cut enough corners to add wiggle room in each engineered joint. Consider a wiggly table with many sugar packets under one of the table legs. This table feels like it does not always help us stand on it to change light bulbs - aka it seems complex, but really it’s only due to imprecision added during creation.
¶Misconception: Being Complex is Bad
It is true that sometimes you have a complex system needlessly. In this regard, complexity should be managed through a process that allows more than one person to weigh in on if the newly incurred complexity has benefits that outpace the cost of living with the new complexity. Complexity is generally the last aspect of how to create an engaging system.
Engaging products tend to be very personalized. Personalization can mean the developers of know all the options at the start, and shove each user down a pre-created option. Or the other option is to say I have a user where we know they have bought these things, have this in the cart, and have rated these other products highly… let’s carve out a place for something to guess the best thing for that person to consider next. The second option requires a completely different culture to pull off.
References:
- 1: Article on LinkedIn by Eric Chivalier
- 2: Post on Google+ by Somebody Else
- 3: Tweet by Joan of Arc
- 4: Article on Yahoo by Samuel Trask
- 5: Article
- 6: Document “Complexity, a conversation with Brenda Zimmerman” by Ricardo Wilson-Grau
- 7: Post on beyondintractability.org
- 8: Post on learningforsustainability.net
- 9: Post on larrycuban.wordpress.com
- 10: Post InfoQ - One person can not know the ramifications of a decision