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 , 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 . software development Noise Argument In software development, the 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 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. Noise Argument tokens The Noise Argument comes up when somebody questions the of a piece of code saying that the syntax is "too noisy" legibility 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 . 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 . Preferably, we need to try to reduce any assumption to a . proximate and ultimate causation smells differently First Principle Given the characteristics of the argument, it can be easily reduced to because a discussion start focusing on irrelevant aspects that are too subjective instead of digging deeper into more fundamental issues. bikeshedding 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 , or . Twitter Facebook Github
