When discussions start focusing on the "noise" instead of the real problem
A visual representation of the Cosmic Microwave Background effect on Planet Earth
Discussions are a fundamental part of software development, they are a necessary friction to increase scalability. A few patterns can emerge from those discussions that allow us to spot problems early when those problems can have an impact on the quality of the outcome. One of them is the Noise Argument.
In software development, the Noise Argument comes as a feedback when there is a piece of code that is stated to be “too noisy”. It is known to come up in code style discussions or Code Review, where instead of pointing out real problems with a given style (when a consistent usage can cause unintended consequences, for example) it is brought up just because there are more tokens in the screen, which most of the time can be considered a personal opinion for being non-agreeable between many individuals, independent on the level of experience.
The Noise Argument comes up when somebody questions the legibility of a piece of code saying that the syntax is "too noisy"
The fundamental mistake is that just because there are more tokens in the screen that doesn’t mean the code is not "legible", which is the ultimate outcome we want to achieve. If this were true then less code would make it more "legible", which is not always the case (some abstractions may omit important information, for example). The predominant factor in deciding if the code is "legible" or not doesn't lie on a single criterion but in a composite of many attributes that due to the characteristics of software development can't be easily perceived by a single individual.
Let's take for example a common consistency rule of always using curly braces in JavaScript conditional statements, used by jQuery Core Style Guidelines at the moment of this writing:
if (condition) {return;}
One could argue that the above is too "noisy" in relation to the approach of omitting curly braces in certain situations when there's a single statement:
if (condition) return;
I have met people that consider the first style better than the second, and others who consider the second style better than the first, both defending each strongly without real arguments that justify such level of defense. Discussions like this can be considered pointless, using the code with curly braces or not can be irrelevant because what really matters is the consistency. This example clearly shows that "noisy" doesn't have strong grounds.
The Noise Argument can be considered a subjective argument with the low likelihood of providing a useful answer
The Noise Argument can be related to the problem of proximate and ultimate causation. Sometimes the "noise" can have a deeper issue — such as dead code or duplication — but the common way the argument is structured fails to expose that, forcing the discussion to lie on the surface. We should try to focus on the ultimate cause of why it smells differently. Preferably, we need to try to reduce any assumption to a First Principle.
Given the characteristics of the argument, it can be easily reduced to bikeshedding because a discussion start focusing on irrelevant aspects that are too subjective instead of digging deeper into more fundamental issues.
The Noise Argument can easily reduce the discussion to bikeshedding
When entering a discussion, take extra care when using the words "noisy" to disregard a piece of code. Assume that there might be something wrong with the claim and that the argument can be improved by digging deeper into why it seems bad, which might unveil the ultimate cause for that line of thought.
The ultimate cause is the thing that really matters.
Thanks for reading. If you have some feedback, reach out to me on Twitter, Facebook or Github.