How To Stop Discussing About Subjective Matters

Dealing with humans is not easy and some arguments are known to drive specific type of discussions

A cat looking at the mirror and seeing itself as a lion

What is "subjective"?

The dictionary explains that subjective is something "existing in the mind", "pertaining to or characteristic of an individual", "placing excessive emphasis on one’s own moods, attitudes, opinions", "relating to properties or specific conditions of the mind as distinguished from general or universal experience".

In software development, the expression "subjective" is used to call out a stated truth or technique that have no scientific evidence and is known to drive useless discussions (e.g spaces vs tabs). There are many ways of providing the solution for a problem in programming, but it's only possible to go as far as the knowledge limits of the team responsible to find that solution.

In software development, "subjective" is an expression used to call out a stated truth or technique that have no evidence of being able to provide a useful outcome and is known to drive useless discussions

One could argue that we have enough tools to remove subjectiveness. The Scientific Method is the result of hundreds of years of philosophy aimed to remove human weaknesses in reasoning, a method that is even able to deliver efficient results for certain aspects among the complexity of the universe. Mathematics provide a way to express thoughts in a way that leaves no room for subjectiveness: there's one interpretation for an equation, and only one.

Somebody could argue that every useful technique can be demonstrated in a way that it shows its benefits clearly, otherwise it can’t be considered useful at all and should be ignored.

However, software is not that simple.

When we are working with a non-trivial piece of software we are not dealing with computers — the computer will do anything we tell it to, — we are dealing with humans. Unlike machines, humans have emotions, opinions, feelings. You can be the most logical person in the world, but you'll never stop being human. That's something you can't change.

Writing software is hard and we need to learn with the experience. I am not talking about personal experience, but experience based on a useful result that may or may not be linked to a practice or technique that is anecdotally or empirically known to work in certain circumstances.

Sometimes a technique that is known to work can't be empirically proved, either because the circumstances can't be reproduced (a team with a certain mindset) or because the cost to run a scientific experiment with a considerable amount of samples is too high.

When we are working with a non-trivial piece of software we are not dealing with computers, we are dealing with humans

, it just happens that sometimes it's our only option. One drawback of not being able to prove a practice besides who experienced it is that it can be claimed to be useful for a general audience but still not be. The opposite is also true.

A video of Neil deGrasse Tyson explaining why eyewitness testimony is the weakest form of evidence known in the history of science. However, it is (in a scary way) one of the highest forms of evidence in the court of law

Although it's impossible to provide the right answer for something that can't be reasonably proved we can still spot common patterns to decide if something is less likely to provide a right answer if they are known to drive endless subjective discussions.

Here are some of these patterns:

• The Noise Argument is when a developer states a piece of code is not legible because it's "too noisy", which is not a very useful argument because the number of tokens on the screen are not a real legibility measurement.
• The Legibility Argument is when the author of the code states the code is legible for other readers, which tends to be wrong because the author of the code is the one that has all the context of what was done.
• The Proper Solution is when someone claims that the proposed way is the best way to write a solution for a problem when in reality there's no best solution, just a solution that is as close as possible to what the team is capable of given the current circumstances.
• Over-Engineering is when someone has apparently written more than enough to solve a problem, which is hard to quantify because sometimes a naive code can have more problems in the long run than an apparently over-engineered one.

To deal with subjective arguments, we need to find the main reason why they exist in the first place and from that try to infer if they are more likely to point to a right or wrong answer based on how they are known to drive discussions and bikeshedding.

Stating that something is subjective or not is dangerous. We need to live with the fact that there are subjective arguments and that they are not wrong by definition. Some of them have the potential to drive endless discussions and prevent us from reaching an agreement, others don't.

If we spend effort trying to recognize them, we will be able to take actions and prevent discussions that don't provide any value.

That is the best we can do to prevent discussions from going on forever and get the job done.

Thanks for reading. If you have some feedback, reach out to me on Twitter, Facebook or Github.