This is the first blog to my small series “My 2 cents about thinking“.
I would say, everybody does it. I assume that about most topics people do it unconscious. Thinking in models.
Don’t forget, this article is not based on any advanced knowledge, studies or books. This is how I explain “thinking in models”.
It is impossible to know everything about everything that we face in our life. Many things are accepted as they are, without spending too much time on how they work. “It works” is the only information needed for those things.
For a lot of things we are able to make connections between similar models and try to adapt the knowledge we have for one thing and project it on to the other.
A couple of things we spend time and try to understand better how they work. Depending on your profession, there might be even a few things where you try to find out nearly everything there is about to understand why it works how it works.
All things have one thing in common. In your mind, you create a model of them. This can range from a picture of that thing with the information “It works” up to something so complex and so interwoven with other models that you have no clue how to explain that model to someone else.
Don’t forget, “essentially, all models are wrong, but some are useful” – as the statistician George Box wrote it.
Your models will be never complete, rarely correct in every aspect, but they hopefully contain enough information to explain most things you need to get explained. If you learn something new about a domain you already have knowledge about, the learning process is much easier. You “just” need to map your already existing knowledge around the new facts. In a new domain you have to acquire the basic set of knowledge for your model first, which makes it more time-consuming.
I had one experience lately at work. One of my team members was testing a functionality I did not yet care about. When thinking about it I had no idea how this feature might work, not even what it was used for. It was only a name. When my team member organized the know how transfer, it took three single terms in the first two sentences of her explanation for me to realize how it works. I was immediately able to relate my existing knowledge and build a small model of the new functionality, that explained most of the things I encountered so far and was sufficient enough for easily understanding the rest of it. The other team member who also got the functionality explained for the first time, took much longer. After the “guided tour”, she needed also the personal experience to grasp the newly learned. I realized all those differences only when I started thinking about why I got it in two sentences and she took about an hour. I tried to understand how she was thinking, how her model-building works, and how I could help her to improve understanding new things faster and how I could explain things to her.
This is the luxury of having a small team. You can try to understand how different team members think and adapt your way of explaining new things to their style. If your team is bigger, you can try to recognize patterns in learning and optimize your way of transmitting the message by the feedback you get. Without feedback from your team or audience you cannot evaluate how good your message was understood. But for all of this you must first be aware of how thinking in models works and you need interest in understand the model thinking of your co-workers.
Most models are tacit knowledge to their owners. I assume that most people don’t know how to explain their models to others. Testers have to deal with that problem every day. A tester gets a piece of something to test, she creates a model of that something in her mind and starts to develop test ideas. When she writes down those test ideas in prose they become test cases, test scenarios, test outlines, or whatever she might call them. The tester explains, sometimes step-by-step, what she is doing, if the reader is lucky even how or why. The more complex the something is, and of course the more creative the tester is, the more possible test cases she needs to write down. And with everything written that information gets longer and longer, and people don’t read it and it gets quickly outdated, because nobody maintains it. So this form of information is a certain waste of time from the moment you create it.
Early in 2013, soon after starting with my current company, facing a problem I described above, I developed an idea of how to document the system we have, bringing all the different customer specialties in one picture without the need to write and maintain test cases with up to 10 different customizations to consider. I started to use mind maps as a model of our system. With the help of tags and filters I brought in the special configurations. I came up with a name, that I don’t even remember now. Because about 6-8 weeks later I read a blog from Leah Stockley describing the idea I also had as “Visual Test Model“. I liked the name, I liked the explanation and I liked the discussion afterwards of how and where to use mind maps in testing.
Lately Aaron Hodder explained using mind maps in testing in this excellent two part series. Part 1, Part 2. With these great explanations at hand I will stop trying to explain how mind maps can be facilitated for testing and come back to thinking in models.
When I think about my models, especially the two systems I currently test, these models are at least 3D. There are some connections between parts of the system that don’t appear in my 3D picture, so maybe there is a dimension in addition to that to cover all relations. This is not practicable when trying to put it down on a piece of paper, a white board or to chisel in stone.
I would assume that most people model more or less in 3D, since it’s a three-dimensional world, people are used to this. But when it comes to putting that knowledge down, we have to transfer the model in 2D. This transfer or translation is a big challenge. You don’t want to loose vital information, but still you want to cover everything.
There are hundreds of modeling languages out there, ways to describe complex things in 2D. Most modeling languages bring good tools to explain special situations. Unless you are firm in using one ore more modeling languages and you completely adapt your way of model thinking to those languages you still have to translate your model to them. Parts of your model might already be reflected in some sort of standardized modeling language, because you are used to it. But I guess for most people they are not or they are mixed up, I can only speculate about this.
In my former company I worked in a big system integration test project with about 200 different business processes modeled into about 20 different systems, interconnected via several technologies. For most business processes I had some sort of flow chart in my mind, how that process looks and works in my mind model. I maintained not one giant model containing everything, I split the model apart and explained things differently, depending on the context. I could even bring in hardware information, systems that share an app or database server. Who wants to know what, how and why. But I only know that now, about 15 months after I left the project I was in for nearly 10 years, when thinking about how I modeled the system back then. I was not aware of this.
But how do I explain the model to others, so that they understand my model and incorporate the information from my model to their models?
In my team I made an experiment rather early in the project phase. I told the team about the mind mapping approach and how to maintain information in them. But I was not happy about the initial model I created, it lacked information. After two weeks experience in the new system I gave them half an hour to draw me a model of the application and I questioned them afterwards. Team member #1 used my mind map and tried to extend it with the new information. Creating the relations and dependencies was not easy, since it was my way of thinking and not hers. Team member #2 used my way of creating mind maps and adapted it from scratch to the new information. She was not happy with it, maybe because she knew how I was thinking and tried to explain her model in my language without knowing all grammar and vocabulary. Team member #3 made my day. He got stuck after putting about 10 items on the screen. He was not able to create connections and he got a black out and was not even able to explain something to me of those 10 items. The problem was, at least I think so, he tried to imitate my language and model, but he mixed up objects and functions on the same level. With this approach I finally added a tool to my tool-box to better explain my model. Thanks to team member #3 and his black-out that triggered me to think more about his solution and where the problem was, I can translate my model now better to 2D. At least in a way I understand it. I’m still working on making it easy readable for others.
When I encounter now a situation where it is obvious to me, that someone has a flaw in his mind model, I try to help with reconstructing the model. We had a discussion the other day, where six people explained their understanding of the functionality. One of the team had a problem in understanding. Instead of explaining him the functionality again, I tried to understand the design flaw in his model and I gave him a hint how to re-model. After a short while he understood the functionality better and was up to speed in the discussion.
Up for me to learn are better ways of translating my mind models to 2D and to other peoples modeling languages.
My tips: Learn as much about anything as you can, you never know when your mind models come in handy for cross-referencing a new fact that you come across. Try to make yourself aware of your own mind models and try to be curious about how others think with the goal to adapt your style of transmitting information.
Next up in my reading list are now the system thinking books from Jerry Weinberg. I’m looking forward how those books will influence my way of thinking about mind models.
Test Pappy 