A human brain is a complex machine that evolved over millennia. It works in the most peculiar ways possible and allows us to excel both at perception, dexterity and mind work. Some of its functions are a bit hacky. There are a lot of stereotypes and shortcuts that our mind takes in order to be more efficient and take less energy to fulfill the task. It helps most of the time although, being overwhelmingly erroneous at times, so that it leans you to the wrong decision, building an incorrect map of reality. The lenses of your perception may be flawed, the mechanism that grinds up the information you collect may be malfunctioning, your mapping can be highly incorrect.
Such errors have a name. This name is 'fallacy'. A fallacy is reasoning that is evaluated as logically incorrect and that undermines the logical validity of the argument and permits its recognition as unsound.
Like other people of mind work, software engineers require a lot of thinking, analysis, and mapping of reality to fulfill their job. While doing these processes, our mind sometimes takes shorter routes to reach the destination, leading to wrong decisions or poor planning. To avoid that it is better to know your flaws.
Mind processes are complex and multicontextual, so are the fallacies one may fall for on the way of thinking. Although, there are some that I consider interesting for a software engineer. Here they are:
Nirvana fallacy (perfect-solution fallacy) – solutions to problems are rejected because they are not perfect. This is the common problem expirienced developers have. They know how things should be, and what would be the best option for the current issue, even though it may be time-consuming and harder to graps from an outsiders perspective. Holistic solutions are beautiful and elegant, but real world deadlines and realities dictate otherwise. It is better to steer perfectionists tendentions to the project architectural uniformity, startup time, environment, log output and other ongoing metrics than attention to one particular piece of code. Even though there are people building cathedrals, most of us work on the Ford assembly line, where proper processes, isomorphy and clean workplace win the day.
Appeal to authority (argument from authority, argumentum ad verecundiam) – an assertion is deemed true because of the position or authority of the person asserting it. When explaining practices or opinions on some subjects of sofware development, project management, operations, e.t.c, people tend to use somebody elses saying, blogpost, conference talk or other claim as a foundation for justification of their own decision. Even though it might not always be fallacious, mostly it is better to add more contextual arguments that apply to specific solution or project rather than appealing to authority.
Historian's fallacy – the assumption that decision makers of the past viewed events from the same perspective and had the same information as those subsequently analyzing the decision. This fallacy frequently arises when a progammer is working with legacy code. It is important to remeber that decisions of the past were not done by people who wanted to do wrong. Most likely, their poor coding standards, entangled code structure or confusing library choise had some reasonable background, related either to hardly structured development process, everchanging requirements or inadequate deadlines. However, there are obviously some really bad engineers out there also.
Misleading vividness – involves describing an occurrence in vivid detail, even if it is an exceptional occurrence, to convince someone that it is a problem; this also relies on the appeal to emotion fallacy. Some engineers may use such fallacy, exposing all the technicalities of their job to cover incompetence and justify failure in rolling out feature in time. It is better to judge on the actual context and possible outcome, not solely on the explanation of fellow engineer.
Survivorship bias – a small number of successes of a given process are actively promoted while completely ignoring a large number of failures. This one is especially important for the people with business mindset that want to open a startup or enterprise. They tend to learn the success stories of prominent companies, which may be an exception, rather then a rule. Thousands of startups fail each year and only a few survive to succeed.
Top comments (0)