Before I begin, I’ll just point out that I’m not actually going to argue that you should never listen to Martin Fowler. That was a trick, I’ve probably been reading too much click-bait.
That being said, consider the following conversation:
Engineer 1: “We should use architecture/design pattern X to build our new project”
Engineer 2: “Should we? Why?”
Engineer 1: Because architecture/design pattern X is really powerful. It’s the way software should be built.”
Engineer 2: “That doesn’t sound like good reasoning. What are the benefits for us?”
Engineer 1: “It solves problem we don’t have Y.
Engineer 2: “Do I really need to explain what was wrong with that sentence?”
Engineer 1: But household name company Z used it to build their system that in no way resembles ours.”
Engineer 2: “Really??”
Engineer 1: “But Martin Fowler said it was good in a blog post once. It is definitely the way things are done these days.”
Continue ad nauseum.
I’ve noticed myself having slightly less exaggerated variants of this conversation throughout my time as a software engineer. The sad truth is that at some point or another, most of us have been both engineer 1 and engineer 2; I know I have.
The problem is, that although the illogicality in the discussion above is obvious, these styles of pernicious arguments when combined with the right irrational attachment to an idea, charisma, authority, or rhetorical skill, can actually be quite convincing.Leading or following someone up the garden path towards a bad design decision is a lot easier than people might generally think. As a result, as engineers we always need to be on our toes when it comes to critical thinking and be aware of the kind of good and bad arguments that might crop up when we need to make decisions.Below are four of my personal favourite logical fallacies and cognitive biases that can appear in software engineering discussions, with examples based on conversations I have had.