Differentiae – where is the difference

In an article from August 2019 my friend Damian Synadinos taught me about the concept of “differentia”. The distinguishing characteristics of a thing that makes it possible to differentiate it from another thing.

In the DSRP-method for systems thinking, D stands for Distinction. It’s all about what a node of the system is and what it is not. Sometimes that’s as easy as, this tree is this tree and not all the other trees around it. Sounds stupid, but can be that simple. Not always it’s that simple. Where do you draw the border between a thing and not-a-thing. And is the border part of the thing or not?

The distinctive element of a node in the system can be very helpful. Let’s go back into the world of IT and look at a service that handles log-ins. This service is responsible for authenticating users. In one case it is not responsible for storing the user’s real name. In another case it is. So it can be helpful in the description of a service what its responsibilities are. It can also be helpful to distinguish what the service is not responsible for. This creates a clearer expectation towards the service. It handles the login, but not the storage of further user data. This defines the borders of the element better.

Maybe you have to dissect the node into smaller parts to find the differentia. Take two types of trees for example. On first sight they might be similar. But then you look at the parts, like the bark, or the leaves, or the fruits. Maybe the bark looks the same, maybe the fruits look the same. But the leaves have distinguishable elements. That might not help in winter, when the tree lost all its leaves. Then you need to keep searching for further distinguishable elements.

The differentia can also help to describe your job. The job description can be a list of tasks that your role has to do. Are there tasks your role will not do? Are there tasks your role could do but doesn’t have to? Where does your role start and end? That a tester is not responsible for finance and controlling might be obvious. But actually, I had that task as a tester once. For a while I was taking care of my team’s controlling. Was that in my job description? Probably not. But was it excluded in my job description? No. Would it make sense to create a job description with that amount of information what your job is not? Not at all. But there might be important details that should be listed, that you don’t have to do. One of the most important elements of the job description for me was: “Don’t need to travel, if you don’t want to.”

When a small child sees a cat, it knows it’s a cat. Cats all look roughly similar. The differentiae are not that huge. Though the same happens for dogs. A small child knows that it is a dog, no matter if it’s a Chihuahua or a German Shepard. The differentiae are quite enormous. But the dog typical elements seem to be clear as well. So there is something about dogs that makes it clear that it is a dog and not something else.

So, it is important to describe what it is, but also to a useful degree what it is not. Next time you describe an element of a system. Think about what it is not. And it will become much clearer what it actually is.

The relation is its own thing

When it comes to systems thinking you can take different routes how to make up the model. I have not looked into the 50+ different approaches to system thinking that I found in a list earlier this year. But I assume that connecting two elements has to be part of every approach, somehow.

When you look at two elements with a relation, the relation is actually an element of its own. In IT one of the more obvious examples is the network connection between a client and a server. On some models it might be just a line. But in reality it’s network cables, hubs, routers, and so on.

Look at it from a service architecture perspective. There are two services. When they are related we sometimes call them provider and consumer. The provider offers a service, and the consumer uses it. So in a model of the system, the provider has an endpoint to offer a service, and the consumer has a client to request the service from that endpoint. Or a service generates an output and provides it via a client call to a consumer endpoint. Clearly those two services are related and share a connection.

Now you can take the silo-route and say the endpoint determines how the message body is defined. Or you can move that interface definition between the two services. Some might call it contract. It is a document of some sort that describes how a request has to look like and what response to expect in return.

So there is now a new element in the model which is the relation between consumer and provider. And the relation is having parts of its own, e.g. the contract with its definitions. You might have heard of contract testing as an approach. Very much simplified, its an approach to test the relation without the availability of one partner of the connection. When both partners have successfully tested the integration with the contract you can assume that the integration between the two services is compatible.

The contract describes the rules for interaction, it describes the way to connect. In a successful live integration the contract is implemented in the services and implicitly used. System A doesn’t send a message to some thing in the middle representing a contract and that hands it over to System B. A sends the message directly to B, respecting the contract. When doing contract testing you replace either A or B with an explicit element as representation of the contract. But that helper is not part of the actual integration between A and B.

Treating the relation as its own element was for me a fascinating insight. And it helped me to cope better with certain situations. Let me give you an example.

In my company I temporarily stepped in as maintainer of our SDLC process. The company produces medical device software, so a rather regulated environment. Accordingly convoluted is our process. I restructured the model behind the SDLC to adapt it to my view on the system from end to end to describe the status quo. The process spans a long time frame and many roles. When presenting the adjusted model I got mostly critique. In the olden days I would have taken this personally. I would be devastated.

What is my relation to the model? I’m the person who tried to visualize a common understanding of all the process steps in the company. These process steps are not me, the model is not me. I collected parts of these steps from other people. The model was reviewed and adjusted. So when the model gets critiqued, it’s the model, or the process or the fact that we work in such a way. I am not this model. I only helped to update the written representation of it.
My actual mental model of this process has reached a complexity that I don’t barely understand myself anymore. Four to five dimensions are needed. While I’m content with the way I described the model, I’m not happy with the actual process it reflects. But that was not me. I barely had influence in any of these decisions. I’m just the person who tried to describe it.

Think about relations around you. Maybe you find examples where you take something very personal, even if something is critiqued, that is not actually you. It’s just related to you. Then look at the relation and analyze the relation. How much of you is really in the something?

As a wood turner I create objects. When someone likes the object, they like the object, not me. When they “hate” the object, they hate the object, not me. I have created the object. Maybe I have put my heart into it. I might be hurt. But the critique is against an object that is the outcome of my work, not me. Two different things. Many people take these things personal, I took these things very personal. Not to that extend anymore, at least not all the time. If someone criticizes me personally, fair enough, then I can take it personally, because it is about me.

If you don’t like this blog post. That is a fair evaluation. If you don’t like the way I think, and you think I’m an idiot. I understand. Maybe I will take it personal. But maybe I will look at the relation between you and me, and then decide if I take it actually personal or not. Because most probably you only come to the conclusion that I’m an idiot, based on my writings or limited interactions with you. If we know each other personally, and interact regularly, and you still think I’m an idiot. Fair enough. Most probably I will agree.

Why am I writing so much about Systems Thinking?

TL;DR: It’s one of the most versatile tools, that should be in everybody’s tool box.

When I think back, I’d guess that at some point in my twenties I became a solid yet unconscious systems thinker. In 2000 I started working in professional IT, and there were systems everywhere. Networks, servers, clients, databases, you name it. In IT we have systems all around us. In the first ten to twelve years, when I thought about a system it was of course an IT system. I showed a solid understanding of the ones I worked with. Sufficiently enough to take some leading and managing positions in the test projects I worked in.

When I joined a new company this skill helped me to rather quickly grasp the new products I was working with. At the same time mind mapping became a thing. So I worked on my skill to visualize systems under test, that supported my testing activities and reporting. I realized that my IT systems thinking skills were very helpful.

Then I found the book “Thinking in Systems” by the late Donella Meadows. And that book opened my eyes. I’m a slow thinker and not the brightest candle on the cake, and sometimes I need a huge hit in the face to see the obvious. Suddenly I realized that everything around me are systems. It was not Eureka!, it was more like Holy smokes! Treating everything as a system was a wild idea for me.
I think one of the first examples in the book was a bath tub. A bath tub! Think about a bath tub as a system. Jeez!

That opened a new world for me. I was ~36 years old. What a waste of time! Suddenly everything around me made more sense. Team dynamics, politics, nature, relationships, economics, everything. Of course I had a basic understanding of all these things. But it never clicked how easy it could be. I became better at systems thinking. I had learned a few tools, I practiced more, it all made sense. I made a giant step in my thinking.

I was happy with the tool set that I got from “Thinking in Systems”. And then I read the recommendation of the Cabrera Labs podcast. After a few months of having it in my list of podcasts I finally gave it a go and I was hooked from episode 1 on. Drs. Derek and Laura Cabrera are looking at systems thinking from the educational perspective, and how to teach systems thinking to people. This is completely IT-free. They offer courses and books and other material as well. The podcast is free, and as a reader of the book I can tell you, that you don’t need to buy the book. You get the content well explained spread across the episodes.

This was now a huge push for me to practice even more systems thinking and to get more active in practicing that skill again. The approach of the DSRP method is actually quite simple to understand. And then it takes practice to get better.

I realized over the last six months or so, just how immensely useful systems thinking is in nearly every aspect of life. Not only in IT. And I want to share that experience, I want to share those insights. I want to convince people to try it. I believe that it helps already young kids to improve their view of the world. It will help them in school to see the connections between subjects that have been isolated and silofied. It teaches empathy, but also the ability to spot motivations they might not agree with. It helps to find their way through the information garbage that is thrown at us every single day. I expect that some folks will do this more naturally. I observed that some mot probably don’t think that way. I can tell you that I have no idea anymore how my thinking worked before reading “Thinking in Systems”.

I hope that makes some sense to at least some. I will try to write some more anyhow. You don’t have to read it. In the end it helps me to make more sense of my crazy brain.

Web of Causation and why I don’t like 5 Whys

Before we start, I have to add, that I don’t like 5 Whys how I have seen it often done. This is my personal, not very exhaustive experience. Maybe your experience is different. In that case, please take a moment and think about what you do differently and how that makes it a more successful approach.

Why do I not like 5 Whys?

In my experience, the 5 Whys approach is almost always used in a linear approach.

Why is it not good to use a linear approach?

A linear approach digs deeper into one direction of what we believe from the start is the root cause.

Why is digging deeper not a good approach?

Digging deeper is a good approach. Remember the post about “zooming in” from last week?

Why is digging into one direction not a good approach?

Things don’t just happen! Let me tell you about the web of causation or web of causality. As a systems thinker I try to see the connections and dependencies between nodes in the system at hand. Nodes might have obvious connections between each other. Or they have more indirect connections, not that obvious to spot on first sight.

So digging is good, but you have to look sideways and around corners as well. You might change direction, or split up and go into different directions at the same time. Of course you can do it sequentially. What I try to say is, there will often be more than one factor.

The web of causation tries to show the relations of different nodes in a system and how they interact and influence each other. The resulting web might look complex by itself. But that is the issue. We often look into a failure of a complex system. And with 5 Whys we try to determine the one root cause.

In my experience, there is a weird fascination of people with one root cause. Why can’t there be two or more? Well there can be and there will be. And we should acknowledge that. A root – of a plant – is not one thing. A root is a huge complex system by itself. We only treat it too often as one thing. And quite often I have heard when listing a set of causes for a problem, that I need to narrow it down to one. Sometimes they allowed me two.

Why did you stop at 4 Whys?

There is no rule to ask exactly 5 times Why. Sometimes it’s more, sometimes it’s less. If you ask too often, the Big Bang is the root cause. Without it, we wouldn’t be in this situation. Helpful? Not at all.

Are there better ways?

I have not done that many formal root cause analysis to have the ultimate answer to this. One way I prefer over 5 Whys is the Ishikawa or fishbone diagram. It’s a simple way to list many aspects of the system that belong to the incident to analyze. Out of the box it forces you to think multi-dimensional by listing many components like process, people, equipment, and mission. It acknowledges the complexity of the system from the very start.

Each branch is looking at one main aspect of the system and then splitting up into its parts again. It’s a way to dissect the system and look into many directions. It doesn’t try to reduce the search to one root cause. It accepts complexity as given.

The Ishikawa diagram has downsides as well. It quickly becomes unreadable like many mind maps. It lacks a good way to connect the dots. Because each branch will have dependencies to nodes of other branches. We are operating in 2D again, where four dimensions is what you need.

Don’t over-complicate; Goldilocks!

The search to identify the web of causation, all elements that were involved in the failure, might be too time-consuming. Find the right level of abstraction. Look left and right, look up and down, and back and front. Come to a conclusion that is actionable.

You can dig deep and land on a decision that person A made 3 years ago. Not helpful today. Also, the decision was not corrected for 3 years. So what about all the decisions to not do something? You can dig very deep. Systems thinking allows you to do that, and to build your mental model, you ultimately will do that. If you want or not.

But when performing a root cause analysis, please, don’t over-complicate. I tend to do that fairly easy, because I see many of these connections. On the other hand I also don’t see many many more connections. Not everything that is in your mental model has to end up in the analysis. But using a multi-directional approach keeps your mind open to understand that there is often more than one reason. Not only the obvious one.

Just fix it!

At the end a small tip. There are issues where you don’t need to make a complete root cause analysis. Just fix it! Life is complex enough as is. We don’t need to learn from every faulty situation. Often individuals learn enough by just fixing it. Don’t over-formalize. Keep it simple.

Perspectives in systems thinking, again – part 2

I want to spend another post on perspectives, as it is such a valuable, yet difficult topic. Perspective is the magic behind empathy. Perspective helps you to get better in understanding your environment. My wife must already be very annoyed with me. Sometimes she and basically everyone, just wants to have an opinion on something. Keeping it simple. Letting off steam. Having something weird to tell. Often I ask her why she thinks the other person might think that way. Taking different perspectives and motivations is difficult.

When I was talking about systems thinking with Vernon some months ago, he raised the question what to do when you encounter a complex situation. Or rather it was along the line, what to do with it to make is simpler again. I had to think quite a while about it. Systems thinking is an approach to understand the system at hand, not to make it simpler. To make it simpler, or rather find out, if you can make it simpler again, you first need to understand the system. Find the simple rules, find the relevant parts, find the connections, and find the motivations. Then you can decide which parts, rules and connections to remove. Taking different perspectives is vital in this part.

A process might include roles A, B and C. There is a strong dependency on some information that A and B need to provide, that C needs. Without seeing the motivation of C, you might wonder, if it is really relevant for A and B to provide the information. To take an abstract example from the world of IT. We are working Agile, so we use Jira. A Jira ticket in our system has many custom fields to fill out that expect partially hard to understand information. It is easy to loose the overview. When you don’t know that downstream of the development life cycle certain Jira queries (JQLs) are used to extract information from the tickets to report a relevant element of the system, you don’t see much sense in some of the fields. Some fields are used to derive other decisions from them. Not obvious to spot in some cases.
For me as team member these information on the ticket are irrelevant. Can’t we just drop them? But not so fast. So, let’s take a journey and take the perspective of the Jira ticket. When you have moved the ticket to “done”, it might not be the end of the process for the ticket. Think about release processes, regression testing, future changes, or simply reporting. Only with the full picture you can decide if some of the fields don’t need to be filled out anymore. Or maybe you can consult some late ticket consumers that there are more efficient ways to get those information. For this you need to take the perspective of other roles involved in the process and their motivations.

Understanding how to take different perspectives helps with gaining better insights in seemingly chaotic situations. Let’s quickly look at the simplicity and complexity of an American football game. For many Americans and people who grew up with football I would assume the game is kind of obvious. For most Europeans it is just a bunch of people piling up onto each other. It is so complicated to observe, as every play is different from the one before. There is no real flow over the course of a game, it is many small flows. It’s a choreography of the offense, that the defense tries to destroy. 11 people on each side acting rather individually and yet as a whole. There are shared and group individual rules to follow.
This comes back to the ant hill comparison of last week. There are simple rules underneath, but the amount of individuals is just too much for many observers. Every player follows special rules and motivations. To understand one play you need to quickly jump from perspective to perspective, player to player, and guess what their individual intention and intention as a group is or was. Receivers running pass or block routes, defense players covering zones, line men blocking in different directions. This is complex and for people invested in watching a game on that level rather exhausting. For the others it’s just people piling up onto each other once or twice a minute.

Often I reach the limit of imagination or mix up too many information to actually take another perspective. For example, there are some political discussions that returning to atomic power plants is the way forward for Germany’s power supply. This opinion seems to be shared by a significant enough number of people to bring it to the attention of the media. So I was trying, actually a few times, to understand what the arguments of the proponents supporting this stance is. Maybe I have “just enough” more information, that it is too hard for me to understand any of the arguments of the “other” side. Maybe I have different or wrong information and am not aware of them. Why are they ignoring these aspects? Do they know about these other information and explicitly devalue them? Often it’s very simple on this level. Follow the money! In that case I don’t even understand what motivation might be behind it, as not even the prospect of earning money seems to be relevant to the usual suspects.

Now I have done something that I hate at some conference talks. When the talk takes 1-3 key messages and repeats them over and over again to fill half an hour. In this case I have used three examples to explain the same topic. My perspective is that some readers might get the one or the other example easier. I hope that makes sense from your perspective as well.

Perspectives in Testing

Testing and Systems Thinking are two activities that overlap widely. In yesterday’s post I mentioned that you can take the perspective of every part and relation in a system.

In software testing a lot of techniques, approaches and methods that we use are ways to actively take a certain perspective of the system. What in systems thinking is reflected by different perspectives, manifests in testing into for example:

  • Testing personas
  • Load and performance testing
  • Failover testing
  • Security testing
  • Accessibility testing
  • Contract testing
  • Acceptance testing
  • Unit testing
  • and the list goes on…

All the listed elements are “just” a different perspective of the system. In testing some of these approaches are viewed as highly specialist activities. In my opinion this may limit a tester’s view on a system, as it’s someone else’s expertise. In systems thinking every perspective helps to add to the system view. The most obvious – testing personas – implements a framework to test or view a system from certain stakeholder’s positions. Contract testing is the perspective of a relation between two parts. Unit testing views a system from a deep zoom into a part.

I don’t want to reduce the skills needed for any of these. Au contraire, I have participated in many of these activities over the last 20+ years. Each of these perspectives takes a lot of knowledge, experience, skills and partially even will power. What I try to say is, that in systems thinking taking different perspectives is a default tool. In testing it needs additional skill sets, and hence is often forgotten or just an afterthought. Being able to examine a system in regards to certain perspectives is all but simple, yet limiting.

One of my favorite books on system thinking is Donella Meadow’s Thinking in Systems. While the elements provided in that book help to describe a system, it doesn’t actually help how to think in systems. At least that is my takeaway now, 10 years after I read it. Still, it opened a world for me.
Apart from stocks and flows, I remember actors and feedback. Actors in the system have different motivations that influence it in a certain way. Feedback cycles help to adjust the system. Especially the aspect of motivations in a system help me a lot to analyze and better understand certain systems.

Taking different perspectives in a system has for me become like having the zoomies. Not only am I constantly zooming in and out of a part. I’m also jumping different perspectives. It must be very hard for others to follow my train of thought. Perspectives can be e.g. events further down the timeline. Bringing the life cycle of all these parts of a system into the picture is often too irritating for others. Just recently I was part of a work group to solve an issue in our current process. While the others discussed the immediate problem at hand, I also looked into the future. I took the perspective of the part, and I looked at it when it is “older” and what else might happen to it along its journey.

As an example for the power of perspectives take ensembling, teaming, mobbing or however you might call it, when more than 2 people come together for developing or testing. You bring different perspectives, experiences and motivations to the same table to collaborate on something. You provide multiple perspectives across multiple layers of the system in parallel to solve a problem. As you start looking at potential solutions, the group applies a lot of filters at the same time to find a good solution. This is effective and an efficient use of time. On the way you build a common understanding of the system, at least at a certain level of abstraction.

For some perspectives I need way more practice to consequently include them in my systems thinking. To bring it back to testing, accessibility testing is one such aspect. I know a fair bit about the topic, but I have to constantly remind myself. Of course, systems thinking needs practice, a lot of practice. The bar to practice is low. You can do it at any time, when your brain has capacity, with whatever you have in front of you. Visually and virtually.

Perspectives in systems thinking – part 1

A former colleague of mine, Martin Schmidt, has commented under my last article about simplifying model views. The right level of abstraction is important to communicate to different audiences. And I can’t agree more.

First of all, perspectives are a really interesting thing in systems thinking. It can turn around a model about one thing into something completely different. Just by changing the perspective. And a system has a whole lot of different perspectives to take. More about that later this week.

I learned last year that putting everything about a process into one view results into two things. As author of the model I know a lot about the process for all different roles. The reader in contrast is completely lost. Why was that? The process I was describing is spanning the whole software development life cycle, from ideation to monitoring in production. The amount of different roles involved in this process is a lot. Now as reader of the process, where do you start looking? How can you identify the for you important bits and pieces. Well, when the model doesn’t support different perspectives out of the box, you are lost.

It is of course too complicated to maintain one model for x amount of different roles or perspectives. So it comes down to what Martin wrote. Find a level of abstraction or a way of modeling to help stakeholders with “finding their way” into the system. For me it needed several discussions, different attempts, and a kind of implicit approval to actually remove most of the details from our process model. Now we are about to release something that I hope provides a simpler view for different roles to quickly find their place in the life cycle and then dig deeper where relevant for them.

In general, this is not a new topic for me, and I should have known better. But I tend to forget things over the decades. Until I remember them again. 10+ years ago, when I was leading a small team, my company started building a new product. Partially based on what we already had, and mostly new. My team was struggling a lot with the new product. It was the time when I tried to map out systems with mind maps a lot to help with testing. What I learned rather quickly – even for my standards – was that a mind map has too few dimensions, and it is hard for someone else but the author to read and understand. And of course our system was too complex.
You have to talk people through the structure. When doing that I still had the strong feeling that most of my team had issues understanding my explanations. It was when I tried to approach it differently. They should map out a part of the systems how they see it. Then I can adjust my model to their language and explain things differently.

In systems thinking you can take the perspective from every part and even relation. And the consumer and provider of a system’s model are also just different perspectives. A system can change drastically by the choice of perspective. For all people and roles this can also be viewed as motivation. When you look at a system model from a certain perspective, keep those motivations in mind. They will explain a lot.

Simplifying the view doesn’t make the system less complex

Sometimes models are too complex to share with a wider audience. Simplifying the model doesn’t make it less complex though. It lowers the bar for engagement.

This is a quick follow-up to yesterday’s post.

Imagine you have a system with many nodes, relations and perspectives. The closer you look, the more details you find. You can put this onto a flat 2D drawing board to visually share it with others. In your head it will stay more or less four-dimensional, at least if you think like me. You might have a clear imagination of nodes interacting, processes happening in parallel (third dimension), and the system changing over time (the fourth dimension). I love system models like that. I really do!

A model of that level of complexity has its many downsides. One of my bigger issues is to explain things in a simple way. I simply cannot. Reducing them to two dimensions is painful for me. For every aspect I explain I want to mention all the relations and dependencies. I want that the person across can build a mental model similar to mine. And that they have all the information relevant to understand the innards of said system.

Not everybody cares about this level of details. Often they are not relevant to the person or maybe too intimidating. When you look at a convoluted process model, it scares people away. When you have a product where you need to read a 100 page manual, you won’t use it. Nearly nobody is willing to go on the level of detail if they don’t absolutely have to (job) or want to (interest, hobby).

Try to abstract the model and simplify it to a view of the system that is easier to digest, at least for a start. <rant> People want simple solutions. People don’t like change. The more detailed you look into a model, the more often someone has to adjust their model. They have to ask additional questions, get clarifications, understand different perspectives and motives. This takes time and energy. And if there is no personal benefit in this, why would you make that investment.</rant>

Looking back to my 2016 workshop “Quality eats process for breakfast!”. I asked a participant to describe me the process of “making a good cup of coffee”. The process was described to me more or less as: Put ground coffee into the machine, put water into the machine, switch on the machine, wait, enjoy coffee. Simple, right? I don’t drink coffee and I rarely make coffee, I cannot evaluate if this results in good coffee myself. But I have two friends who know a lot about coffee. When talking or just listening to them, I heard things like roasting of beans, coarseness of grinding, water temperature, pressure, pre-heated cups, and so on.

What I try to say is, when you simplify a model, the complexity beneath it doesn’t go away. You just lower the bar for time and energy investment to start looking into the topic. Creating a simpler view of a topic doesn’t actually simplify it. And remember that you have started with a simple view on the topic yourself. Then you started digging. Now is the time to simplify again what you learned and maybe improve the simple view. Provide a better simple view than what you started with.
This applies to every topic around you. Products and processes, companies, cities, countries, relations on every level. There are simple views that help to survive, but if you want to understand the system, start digging.

I started in IT in 2000. And the motto of the company I started with was “Plan – Build – Run”. Yes, you can simplify IT projects to that degree. We all know that the reality is not that simple. IT projects have a lot in common with sausage making. When you know too many details you might not want any more sausage.

When I look into my hobby of woodturning, the complexity is shear endless. And I have only scratched on the surface over the past 15 years. Take a piece of wood, put it between centers, start the motor and hold a piece of (sharpened) metal in the way of the wood until you removed everything that you don’t want. That’s as simple as you can describe it. Or wait: A potential buyer might not even be interested in the process, as long as a piece of interest is on the table to acquire. Magic happens. Bowl appears. Want bowl. Done! Is that helpful? To some it might be, and the others need to start asking questions.

Be curious, ask questions, dive deeper and enjoy the complexity.

Simple is not the opposite of complex

Simple is not the opposite of complex. Complex systems are made of simple rules.

“This is too complex, we have to make it simpler.” I would assume we have all heard this sentence at some point or another. Be it about political decisions, processes, products, forms and so on.

You don’t just make a complex system simpler.

My proposition now is that if someone finds something too complex, they have not understood it. Of course, the world around us is getting more and more complex. And we don’t have the time to understand everything in the necessary depth to make sense out of it.
BUT, if you are in control over a situation and you find it too complex, please, don’t try to make it simpler without understanding it first. Maybe the system is not that complicated after all, when you understand it better.

Any complex system is made up of simple rules. All systems have nodes or actors, relationships and perspectives. And each element of the system follows simple rules. It’s the amount of rules and interconnectedness of rules that make it not so easy to understand. And yes, it is a lot of work to dissect a system to understand all the rules, relations and motivations.

Tangent: Ant Hill

An ant hill is a complex system. It consists of thousands of individual animals. And yet, something like a structure is visible when looking at it. But why? For example, ants follow simple rules when collecting food.

  1. When a scout finds food, take a piece and bring it back to the ant hill
  2. When bringing food back to the ant hill, drop pheromone
  3. Workers follow the pheromone
  4. Never cross the path!

This behavior leads at first to slightly chaotic movements that quickly bring structure. As more and more ants follow, the shortest path between ant hill and food source evolves, and the classic ant roads can be observed.

Complex systems follow simple rules. So when a system is too complex, try to find the simpler underlying rules.

Relations between rules and the web of causation

When simple rules are identified, certain actions or rules might sound irrelevant. Now what makes a system complex? Simple rules, but not just a loose collection of rules. These rules have dependencies. Not every rule with every other rule, but most probably a lot. These relations build a web of causation. An unwanted outcome of a system will most probably rely on multiple factors that went wrong. Things don’t just happen.

Understand the action and reaction between rules! And understand the relations between rules before you remove one. It might cause havoc later down the line.

A simple example

Let’s simplify a form where you have to enter your address and merge the house number and the street name into one field. When the address label is printed later it uses an address validation service. That API expects street name and house number in separate fields. The number field is now gone or empty. So you have to somehow implement a function to split the field again in a way that makes sense.
This might have caused delay in delivering the next version, as you had to wait for the function in the address validation service to be adjusted. Or in a worse scenario your address validation failed too often and someone had to manually intervene with the system, causing a jam of orders. Or even worse, the address labels are now printed wrong and a certain percentage of your mail doesn’t reach its intended destination, which leads to unhappy customers, more work in customer service, and ultimately in loss of money. And that only because you wanted to make a form look a bit simpler.

Wrong assumptions

Understanding a complex system can be an overwhelming and time-consuming task. And while there are good heuristics that help us to understand things faster, we should still question those assumptions. Especially when certain outcomes of reality don’t match the working state of the mental model. Keep observing the system.

Complex Adaptive Systems

While this topic deserves several books on its own, I want to emphasize the dynamic part of systems. Systems evolve, adapt and adjust. Many systems seem to have a self-healing mode, which is simply driven by strong motivations within the system to survive in some way or the other. When you remove one element (a node, a rule, a relation) the system might be able to stabilize itself without “external” help into a state that you still observe as “healthy”. You could come to the conclusion, that the removal of the element didn’t cause any harm, because in your abstract view of the system you cannot observe any evidence against it.
In climate change discussions you will often hear about the tipping point. And that is when a system is not able to stabilize back in its former state without intensive external investment of energy and it will fall to a new, “lower” level, that it is able to sustain – maybe.

Be careful when removing for you obviously irrelevant elements of a system! You might not understand what just has happened. Remember the web of causation.

I could tell you several examples from science, work or the wood workshop. But for the sake of simplicity of this article I don’t.

When a tester gets the zoomies

Testing is a lot about zooming in and zooming out. When zooming out leaves the product borders, it’s about more than just testing.

Zoomies actually describe the frenetic random activity periods that dogs and other pets have. They are random bursts of energy in which they run around frenetically.

Then there is an activity as part of Systems Thinking which is zooming in and zooming out. According to studies at the Cornell University people tend to not zoom out. Nearly everyone zooms in, nearly no one zooms out. I think that I’m part of “nearly no one”.

In Systems Thinking theory zooming in refers to breaking up a whole into parts. Then taking a part and breaking it up again, and so on. Zooming out is taking a whole and looking at it as part of something bigger. Then taking that again and look what it’s a part of. When using different perspectives zooming in and zooming out is not necessarily a repeatable process.

Example: add a new field to an existing web form.
Zooming in:
  • what type is that field on the UI, how large is it, where is it positioned
  • when sending the form, what type of field is the parameter in the e.g. JSON
  • when processing the field, how is it parsed and treated in code
  • when it ends up in the database, in which column does it go, what is the definition of the column

We are taking a new requirement (field), breaking it down into its parts (UI, API, DB). And then we are looking into each part and go into more and more details.

Zooming out:
  • what form does it belong to
  • what is done with the data after it’s being stored
  • which other elements of the product are impacted
  • what does that mean in terms of deploying
  • are there other dependencies when delivering the new feature
  • do we have mechanisms in place to deliver such a change in a safe way
And then there are the zoomies, constantly zooming in and out:
  • new field in the database -> do we need a migration script -> impact on other fields -> impact on other functions
  • migration script -> could there be runtime issues, what about the performance, do we need a downtime -> do we have everything in place for a downtime
  • delivering the new version -> migration script -> rollout, what happens in case of failure -> how to rollback the migration script
  • migration scripts -> do we have mechanisms in place to run migration scripts, do we have mechanisms in place to automatically roll back the migration
  • rollback of the migration -> what is the process looking like, whom to inform, what to document
  • rollback of the migration -> what impact has the partial rollback on other elements of the delivery, do they need to rollback as well

And so on. This is what partially goes on in my head within seconds. Call it ADHD, hyperfocus, bonkers, whatever you want. This is only a tiny fraction that goes on in my brain, when I hear about a new requirement.

Systems Thinking is about constantly improving, adjusting, correcting, extending, and much more of our mental model. The product and its elements are only one part of this. The ecosystem of the product, the process landscape, teams and roles, the company and the customers/users are also a part of the mental model. And I don’t stop at the product borders. When I see something is missing in the process landscape or not supporting good enough, I tend to try do something about it.

I know a lot of people who are very good at zooming in. I also know that a good portion of them is also zooming out. But too many stop at product boundaries. When it comes to evaluating risk and impact, zoom further out. Look at the bigger picture. Practice to zoom in and ZOOM OUT!!! Understand the bigger picture beyond the bigger picture.

Design a site like this with WordPress.com
Get started