When more than one person develop the same piece of software, there are going to be different points of view and different criteria of what is acceptable. But usually the objection is not as clear as yes/no.

If one side of the pair expresses their concern on something, the other side will always respect that and stop so both can focus on it before continuing.

Sometimes, a concern cannot be deferred and need to be addressed right away. Maybe something that will affect the correctness, maintainability and/or clarity of the system. If you are pairing, you can identify this, for example, when your pair says (or you say): I don’t like this.

Sometimes, you can hear the same words to mean a personal preference on how to do it. This objection should not be given that much importance. In this case, it should be treated as a suggestion and not something to spend nearly as much energy as the previous concern.

And these two examples are not the only cases. In my short experience, I found the need to communicate concerns with very different importance levels. Sometimes, while trying to communicate those, the importance level was not clearly transmitted to the pair. As a result, we ended up giving too much importance to something that is unimportant.

What if we had some defined way of quickly expressing the importance of an objection? What if we qualified with numbers from 1 to 5 how important a concern is? 1 being the most important, 5 the less.

They could mean:

  • 1- Stop, let’s address this before continuing because it is critical.
  • 2- There is a thing that is bugging me, but we can defer it for a bit.
  • 3- I have an opinion about this and need to know where you stand about it so we find common ground.
  • 4- I’m fine with how things are but want to propose the following in case you think it is better and want to take action.
  • 5- I’m just saying this because I think it could be interesting for you to know how I see it, but I don’t expect any action.