Critical thinking in software development, the word ‘should’, and why you shouldn’t listen to Martin Fowler

Posted on
Example: “I’ve been learning Docker and Kubernetes in my spare time. I like them very much, and we should deploy our app using them, because they are the new industry standard way that businesses are deploying their apps.”

There can be no doubt that Docker and Kubernetes are fantastic tools, but the fact that they are new and becoming accepted as an industry standard does not necessarily mean you should adopt them. The statement above is a weak argument on its own. This is because it is another example of an area where there are much more important and heavily weighted considerations:

  • Assuming they don’t already have experience, your team is now going to have to learn both Docker and Kubernetes. Is it worth it compared to simpler approaches?
  • When you make new hires in the future have you considered that you are either going to have to teach them, or require them to know this already?
  • There are certainly much simpler ways of deploying software than using this strategy. Are you sure want to commit the time and resources to this?
  • Are you able to empirically demonstrate that you are likely to see enough benefits from the switch to the new technology to compensate for the costs of the above points?

Again, if the answers are “no”, perhaps this needs more detailed consideration. It seems like an endemic number of developers, particularly skilled ones, have a tendency to get bored with what they are currently doing and like opportunities to stretch their wings and try out new and different things. It is always worth being very aware that this may cloud their judgement when making key decisions. It is worth remembering that often the simplest solutions are the best.

This is of course not to say that any of the propositions in the above examples are bad in all cases, in fact, many of them are great solutions to the specific problems that they were designed to solve. The point is that if you are making considerations to your architecture and code choices, do not allow logically fallacious claims and cognitive biases to slip into the mix, and stick to the facts of whether the proposed solution actually matches the problems you have. This is done through careful, nonpartisan consideration of the merits and drawbacks in all cases.

Prev6 of 6Next

Leave a Reply

Your email address will not be published. Required fields are marked *