Tuesday, August 21, 2012

Five Fatal Logical Fallacies of Software Development

Source:Carlos Botelho, CC3.0, via wikimedia

Fallacy Fallacy

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.


  1. The sunk cost fallacy is one of the most dangerous fallacies ever. Why should I stop working on this project when I already spent a lot of money and a lot of my time.

    Sunk costs are the main reason why people don't quit on already dead projects.

    You stakeholders may not thank you, but you will not be doing a favor to yourself, and neither to your stakeholders if you continue working on such a project.

    As a software developer, I have learned this lesson the hard way!

    1. Great observation, itoctopus! Wall Street calls this fallacy throwing good money after bad. How much we've 'spent' on an investment should never be a reason to continue with the investment.

      Some projects, like investments, aren't worth pouring more resources into. As engineers, we ignore the lesson of this fallacy at our peril!

  2. That is some inspirational stuff. Never knew that opinions could be this varied. Thanks for every one of the enthusiasm to supply such tips here. https://www.btcsoftware.co.uk/making-tax-digital/

  3. This comment has been removed by the author.

  4. This blog has great tips for employee timesheets, time tracking software, mobile time tracking apps, timesheet calculators, time clocks, and workforce management software for small businesses of all types and sizes. timesheets

  5. A further problem outlined by Ko is that of programs which were intended to be temporary and owned by a particular person becoming central to a company, this often happens with spreadsheets.Database Diagram Tool

  6. This expands the significance of utilizing publicizing to build up a brand name and subsequently produce shopper commonality and trust. Angular testing services software testing

  7. At that point the article considers three snags that frequently debilitate organizations from making their ERP dream a reality: exercise prescription software for clinics

  8. Please let me know if you’re looking for a article writer for your site. You have some really great posts and I feel I would be a good asset. If you ever want to take some of the load off, I’d absolutely love to write some material for your blog in exchange for a link back to mine. Please send me an email if interested. Thank you! .Net FrameWork Offline Installer