DEV Community

Cover image for Architecture decisions: the belligerent contrarian and the rule of three
Dan Lebrero
Dan Lebrero

Posted on • Originally published at

Architecture decisions: the belligerent contrarian and the rule of three

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.

Top comments (8)

skittishsloth profile image
Matthew Cory

Great stuff! I love being belligerent and contrary and now I can say there's a reason :D

Will definitely keep this in mind and share it with my team. We're still in an early stage of our project, and we've got some junior-er devs who could stand to benefit from these ideas as well.

danlebrero profile image
Dan Lebrero

Thanks a lot for the feedback!

qm3ster profile image
Mihail Malo • Edited

The problem is, even if you do say you were playing devil's advocate afterwards, people will send you this:
I was only pretending censored

In the general case, how to not let the team devolve into hatred and violence when such deception takes place, even if only in the short term?

danlebrero profile image
Dan Lebrero

My only advice, which I understand is not generally applicable, is to do it only if

you have to be comfortable with your status within the company and the people in the meeting

You also have to go prepared, so you have arguments for the pros and cons of each of the options.

In the case that you get to play the contrarian, it is "you" vs "the rest", so as long as you don't take it personally, the rest of the team will not exercise in any violence against you :P.

And I am talking about technical decisions, not political decisions (inside the company). Political decisions are a different beast.

Technical decisions are not about "me" winning. It is about making an informed and rational decision. You have to be open to being wrong.

Note that a rational decision must take into account the irrational human nature, so sometimes you have to be open for the team to be wrong, as the team owning a not-so-great decision can actually be better than a team being forced into the best-in-class option.

thecodingpanda profile image
Simon B

This is great, thanks Dan!

nhono99 profile image

Awesome! I'm working my way to become a software architect.

leppercameron profile image
Cameron Lepper • Edited

Thanks Dan, this is a great post and is super relevant to me just now, so brilliant timing! :-)

danlebrero profile image
Dan Lebrero

Glad it helps! Shout if you need any help!