Image attribution: geralt on Pixabay.

Here are a couple of simple rules that have helped me a great deal on my years as a software architect.

The rule of three

The first rule is that, when you have to make any decision, there must always be at least three possible alternatives in consideration.

To find this third option, we will need to look at the problem from unusual and novel angles or bring back options that were discarded because we thought they were obviously wrong.

This is basically a way of enforcing brainstorming, but using a clear rule and not calling it brainstorming, which in my experience somehow helps.

The rule of three

The second rule of three is that there must be at least three people involved in the decision.

It is very unlikely that all three people will have the same background and bias, so the alternatives will be looking at from more diverse points of view.

The belligerent contrarian

Having three options and three people in the room is useless if everybody has the same preferred option. There must be at least one person that disagreed with the group and have a good reason to prefer a different option.

If there is no such person, then there is not going to be a real debate about which option is the most adequate, as we all will be biased to make sure that our preferred option looks the best. Having to defend our position will make it very obvious if we have solid reasons to make that choice.

Unfortunately, a lot of times there is no such person, which means that you must be willing to defend one other option, even if you think is not the best one.

This means that you have to make sure that you are the last one on expressing your opinion, so that is the rest of the group all choose an option, you can pick another one.

But it also means that you have to have a deep understanding of the weaknesses and shortcomings of the preferred option, plus the benefits or possible benefits of the other options. This is an excellent exercise to look with honesty at your own choices and to make sure that the group understands the trade-offs.

Being the belligerent contrarian is not a comfortable position as a lot of times you are going to be defending a position that looks silly or that is obviously wrong, which means that you have to be comfortable with your status within the company and the people in the meeting. This role is not suitable for junior architects or if your ego doesn't allow you to be wrong.

If you decide to play this role, it is important to not say "I am playing Devil’s advocate" as if you do so, people will not take your position seriously. If it makes you feel more comfortable, you can say so after the decision has been made.

The rule of three

And as we are talking about the rule of three, I cannot pass the opportunity to mention a design level rule of three: there is no duplication until you have three copies of the same code or logic.

The third time that you write the same piece of logic is when you can evaluate if it is worth moving that piece of code to a common library or class.

Until you have three samples, you cannot be sure that the common code will actually be common enough.

It is surprising how many times the new third option turns up to be the one implemented, either because we find a better alternative or because we get over our biases.

Playing the belligerent contrarian, or devil’s advocate, is sometimes fun, sometimes annoying, sometimes distressing, but at the end, having a good debate about the options means that the team ends up moving with more confidence on the decision made, and it is more aware of the possible pitfalls.