Well, actually you should. The difference between a complex and a complicated problem/system makes all the difference, starting from the approach, the way you measure the success and of course the probability of reaching an outcome.
Last article I mentioned the “complex systems”, what is the deal with them? Well, before we go there, we first need to go through what each of these things actually mean.
So, systems. We hear this quite frequently many times a day. So many times we hear terms like the “subway system” or the “train system” or better yet the “Software system”. So what is this system?
A regularly interacting or interdependent group of items forming a unified whole.
So, in this case, I believe that intuitively this is quite easy to grasp, and frankly, I don’t really think that this requires much more explanations. So let’s move on.
Complex or Complicated?
Good question. And as you imagine there is not n easy answer here, I mean there are books written on this subject, but I will do my best to point out the main difference between the two, of course in the context of systems.
First the definitions:
Complicated — consisting of parts intricately combined, difficult to analyze, understand, or explain
Complex — a whole made up of complicated or interrelated parts
Okay, so to illustrate the difference, we will go through a few examples.
A complicated piece of machinery, let’s say you laptop, or pc the smartphone that you are reading this on, is it complex or complicated?
Well, it is complicated.
The traffic on our commute, is it complex or complicated?
Why ? Well, the main reason is “causality”. In a complicated system you can establish causality, You could, or better said a subject matter expert, can properly identify each component and the effect it has on the whole system. So, in the case of a smart device, we can assume that if we need it to run faster we can add some more ram. On the other hand, for a complex system, we can have an idea of how it works, we can not really know how the system will react with certainty. For example, for the commute traffic, there are a myriad of possible things that can influence your time to work. A garbage truck, an accident, weather conditions. But more than anything, and this is more or less why the traffic is a real problem, and particularly hard to optimize ( hence the joy of commuting), is that people interact in it, and people are highly adaptable, so one can not know for sure how the traffic will react to let’s say a new round-about or a new stoplight.
As an exercise, what kind of a system would a middle school kids party be?
Great, so what?
Well, although as interesting and mind-stimulating this kind of exercise might be, one good question would be “to what end?” or as some of our younger acquaintances would argue “why bother ?”
Well, in the field of software engineering it turns out to be quite important to know the level of complexity ( or rather the type of system) of your problem space. Depending on where you are, it makes a world of difference in your approach to the software development practices, patterns, architecture … well actually everything is impacted by the type of problem you are trying to solve, and if you pick a bad approach, well the consequences are quite dire.
Remember from the last article, that most software projects fail ? Well, most of the blunders are correlated to a wrong approach and miss categorization of the problem domain.
So, hopefully, now that we cleared a bit what the differences between complex and complicated are, we could start looking into more meatier (is this a word?) discussions.If this strikes your interest here is a video about the cynefin framework, which is a very interesting concept, “a sense-making” framework developed by Prof. Dave Snowden (Nope, it’s a different Snowden), that helps us navigate each of the states.