Common logical fallacies and cognitive biases in software design decisions
1. Argument from authority
Using an authority as evidence in your argument when the authority is not really an authority on the facts relevant to the argument. As the audience, allowing an irrelevant authority to add credibility to the claim being made.
Martin Fowler says domain driven design is good on his blog, let’s use that. DHH says TDD is dead. Troy Hunt says don’t take security advice from psychics (actually, I’d probably always listen to this one…).
I don’t mean to say that these authority figures don’t know what they are talking about, they certainly do. It is just that the facts relevant to the argument are the technical and domain details of the project in question, not the abstract discussion of the generic application of solutions offered by the experts. Abstract discussions about best practices are interesting and informative inputs to your problem solving process, but are only indirectly relevant. Martin Fowler does not know your technical or business problems.
Example: Let’s use Domain Driven Design because well known expert software developer Martin Fowler advocates it on his blog.If you are unaware: domain driven design is a software development approach for modelling your business domain in your code and creating a shared language between tech staff and business experts.Martin Fowler clearly evangelises domain driven techniques on his blog and he sure knows his stuff, so choosing it for your project must be a no-brainer right?