When to go from collaborative modelling to coding? Part 1

When we are asked to consult companies to help them start with Domain-Driven Design and collaborative modelling¹, it is often because people started to experience the downsides of just coding. They lack direction and see more mistakes being made and more time being wasted because of the “just coding” approach. So they read up on Domain-Driven Design and collaborative modelling and understand that they are missing shared knowledge and models between the developers and the domain experts. They want to fix that with collaborative modelling and think that this will be the solution to all their problems and they call us to help them with this.

So we go to the company and organise a collaborative modelling session, and it goes really great for a while. We gain new insights, we start seeing the big picture, we explore possible solutions, we design a shared model and language with people who don’t understand code. But after a while, the group starts getting torn. Some are sitting on energy and feel like they are not learning new things and want to get back to coding to figure out the details. The other part of the group still wants to keep modelling, because they want to reduce more risk before making costly decisions or mistakes. So they look at us, the “experts” on collaborative modelling and ask us what their best way forward is now that the group is divided. And for a very long time, the best answer we could give them was “it depends…” Until we discovered polarity mapping.

When we discovered polarity mapping, we understood that the reason it is so difficult to answer those questions is that we were looking at these questions in the wrong way. We look at them like it is a problem that needs to be solved, instead of what it actually is: a polarization that needs to be managed. Understanding polarity thinking taught us a lot about the “it depends” dilemma and we want to share our discovery with you in this two-part series.

In this first of two blog posts, we want to introduce you to polarity thinking. You’ll learn how to visualise a polarity on a polarity map, and how using this map will help you manage a polarity properly. This will help to move from either/or thinking to both/and thinking, so we can include all relevant and minority perspectives from the entire group to properly manage our polarities. We will use the question “when do you go from collaborative modelling to coding?” as an example throughout these blog posts.

In part two of this series, you’ll learn how to spot a polarity in the wild, by recognizing the difference between a problem that needs to be solved and a polarity that needs to be managed. We will discuss some of the most common polarities we’ve seen as consultants and help you to prevent the self-fulfilling prophecy antipattern.

So, back to our divided meeting room. A couple of people want to continue with collaborative modelling, we call these people crusaders, and another part wants to go back to coding instead, we call this group the tradition bearers. Both believe that it is either collaborative modelling or coding that will solve the problems that they are facing. Both are wrong. 

Collaborative modelling and coding are not solutions to problems, they are poles that need to be managed, balanced even. This “collaborative modelling vs coding” is what we call a polarity; two sides of the same coin that affect each other, like breathing in and breathing out. Both poles have positive and negative effects. You can’t choose one and think that the problems that arose are solved now. What we need to do is start managing the polarity, because if we don't, we will (over)compromise or stay on one side of the polarity and experience the downside of both sides. 

The first thing we do is get everyone on the same page: this is not an either/or situation and both have positive and negative effects. We do this by using a polarity map.

Visualizing a polarity

A polarity map is a simple visualisation tool that will help you manage a polarity:

A polarity map exists out of four quadrants:

• The left quadrants represent a pole, which we will refer to as 'L'
• The right quadrants represent the other pole, 'R'.
• The upper quadrants represent the upsides of each pole
• The lower quadrants represent the downsides of them.

If we combine those two divisions, we get L+, R+, R- and L- respectively.

If you look at the empty polarity map above, you will see that L+ and R- and L- and R+ have the same colour. That is because those quadrants are connected. The downside of one pole will be the upside of the other pole. One of the negative effects of designing is that you don't know if your model works, implementing your model will let you know that.

The last thing on the map is the lemniscate in the middle, better known as the infinity symbol. Fun fact: lemniscate comes from the Latin word lēmniscātus and means "decorated with hanging ribbons". This symbol represents the never-ending balance you need to find when managing a polarity. There are actions that you will need to take when you start experiencing too much of the downside of one pole. Those actions will move you to the opposite quadrant, the upside of the other pole, but more on that later!

How to fill in a polarity map?

There are a couple of ways that you can fill in a polarity map.

The easiest one is to start in the upper left quadrant, L+, and follow the infinity loop. The order to fill in the polarity map would be L+, R-, R+, L- in that situation.

If there is a clear division between crusaders and tradition bearers, you can start with the negative side of the opposite pole of the minority and then move to the positive side of the minority pole. For example, if the design is on the left, and implementation is on the right of your polarity map, and 10% of your group wants to focus on implementation, start with L-. After that, you just follow the infinity loop again, which would give you: L-, R+, L+, R-.

The hardest way to fill in a polarity map is to start with the positive sides of both poles. The reason this is the hardest way is that it is a lot easier for people to come up with downsides then it is to come up with upsides of something. Just think about all those job interviews that ask you to sum up 3 positive and negative things about yourself.

Those negative qualities are always easier.

Filling in the polarity map

Now let’s start filling in the polarity map with the polarity that popped up during our collaborative modelling session earlier in this post. The group began to polarise between collaborative modelling and coding. Since they asked us to facilitate a collaborative modelling session, we with the group start filling in the map at L-. We continue with filling in the positive side R+, the solution as the collaborative modelling pole. You might recognise we started to visualise the conversation we explained at the start, the problem and solution to why they invited us.

Polarity map, Barry Johnson

When the group started the polarise, you felt some people in the group already experienced the downside R- of the collaborative modelling. They said they were sitting on energy, the model was still too broad and shallow, and they needed to be guaranteed that it could compile. They want to experience the upside from coding L+ by feeling accomplished with writing code that delivers the value and learns from the action. So we fill those sides in as well.

Polarity map, Barry Johnson

The last thing to do is to fill in the “++” and the “--”. The “++” captures the essence of the upper quadrants (what we strive for), the “--” captures the essence of the lower two quadrants (what we are trying to avoid). This will make it easier to talk about the polarity map. For this polarity, what we want to strive for is domain oriented programming by balancing coding and collaborative modelling, and what we want to avoid is shallow technical programming. We now filled in both sides of the polarity map and gave the positive and negative effects a name.

Polarity map, Barry Johnson

If you would ask multiple people to fill in the polarity map, you will roughly get the same polarity map, apart from some contextual differences and the language we are using. What is important before managing a polarity is that we now created common ground, a shared understanding of the polarity that we need to manage.

Actions and observations

Now that we have a clear picture of the polarity, it is time to focus on managing it. As mentioned before, if you get stuck in a pole for too long, you, or other people on your team, will start noticing the downsides of it. These are called “signals” or “observations”. They tell you when it is time to move to the other pole. 

Polarity map, Barry Johnson

Signals and observations will be context-dependent, the signals you discover for one group will be different than for another group. For example, “Adding lots of comments to make it clear what your code does.” will not be observable in every team you encounter. If there is no culture of adding comments to code, this will not be present.

Signals can be formulated with a threshold, which will make them measurable, but we prefer not to do that. For example, the signal “Feeling confused about your own code.” would be “You need to read your code 3 times before you understand it again.” Measurable signals shift the focus of managing the poles to “sticking to the threshold of the signals”, people start to focus on whether or not the threshold was met instead of the observations itself. We recommend making them measurable when you start using the polarity map and then slowly move away from that.

Now that we know what to look for, it is time to think about moving between the two poles. In order to get unstuck, you need to take steps to get to the positive side of the other pole. These are called “actions” or “heuristics”.

 

Polarity map, Barry Johnson

An action can have a one-to-one relationship with a signal, or it can have a many-to-one relationship. “Model the comments from your code” is an action you take when you observe “Adding lots of comments to make it clear what you coded.”, but “Model the scenario that is most unclear.” can be done for all signals that you observed during coding.

Polarity map, Barry Johnson

And there you have it, a map for managing coding and collaborative modelling in detail:

“It depends” has now been turned into signals you need to watch out for and actions you can take. More importantly, the “coders vs modellers” is no more, everybody on the team is on the same page. It no longer depends and our job as a consultant is done. ;-)

Roundup

In this blog post, we had a look at what a polarity is, how to visualize it and find signals and actions to manage it. In the next blog post, we will dive a bit deeper into how to recognize a polarity and what can go wrong when you try to manage one.