|Source:Carlos Botelho, CC3.0, via wikimedia|
Drawing the conclusion that another engineer's point is incorrect because he cannot adequately defend his position.
Don't immediately disregard somebody's opinion due to poor argument construction. We often have an intuition about engineering solutions — an intuition that isn't always easily quantifiable into a well formed argument. You should seek first to understand the possible reasons for taking an opposing position so that, ultimately, your designs will be better informed. Moreover, if you are in a decision making position, your decisions will be viewed as more fair and well thought out.
Appeal to Tradition
Justifying or defending a coding practice by citing precedent.
I encounter this argument all the time when introducing new software into existing systems. It is usually an internal struggle between introducing newer, more well thought out designs vs adopting a 'When in Rome do as the Romans do' strategy to maintain consistency in the code base.
Processes, procedures and coding practices aren't developed in a vacuum. There are a dizzying array of external factors that influence these decisions. Many times, if you examine the factors that led to these decisions, you'll find that the original reasons no longer apply or are diminished. It never hurts to apply the five whys to find out if it makes sense to continue a particular practice.
The Sunk Cost Fallacy
Believing that you must continue forward with a particular design, project, etc. because you've already poured too much time, money and other resources into a solution.
Software engineering is hard. We never have all of the facts when we start a project. We should not be afraid to change direction once new information leads us to question the viability of our original decisions.
Is that refactoring effort that you thought would take 2 days instead proving to drag into 2 weeks with no end in sight? Don't be afraid to stop because you now know that its more involved that you originally thought. Cut your losses. Your project deadline and your stakeholders will thank you for it.
The False Dichotomy
Constraining a problem space to two — and only two solutions.
I encounter this most often when troubleshooting production issues that aren't yet well understood. Statements like the following are often made: 'The slow performance is due to either a missing database index or a changed execution plan from crossing a partition'.
While these may be likely culprits, such statements ignore an entire universe of other possibilities including JVM GC pauses, network latencies, etc. Rarely are there only two possibilities when dealing with undiagnosed problems.
Confusing Correlation and Causation
Assuming that because events occur together that one must cause the other.
This is another fallacy that tends to be seen when troubleshooting production issues. In such situations, reams of data are analyzed and we humans do what we're best at: pattern recognition. If we're not careful, this pattern recognition can lead us to assume that one event causes another to occur.
Incorrectly asserting causation is dangerous in this case because it can lead us down unproductive exploratory paths and thus lead to longer diagnosis times. Knowing in advance that events are correlated but not necessarily causal can introduce a healthy dose of skepticism into the troubleshooting process.