I believe that many of the arguments we have around software development practices could be avoided by the simple understanding that all of our mantras need to be understood as proverbs and not laws.

If you understand proverbs, then you’ll know that every proverb has an equal and opposite proverb.

So, that means it’s fine to say DRY - Don’t Repeat Yourself, and also WET - Write Everything Twice.

It means it’s fine that we quote Knuth saying premature optimization is the root of all evil, while also believing that Performance is a Feature.

We can understand and apply separation of concerns, while also seeing the value of locality of behaviour.

There is a time to YAGNI, and there is a time to refrain from YAGNI.

None of the above involve logical contradictions. Proverbs encapsulate a small bit of wisdom in a pithy phrase, but you still need to learn to apply that wisdom correctly.

Good proverbs are also supposed to make you think. They slow you down before you leap into something that is likely to be bad, or they help you reflect on what did go wrong.

One pair of Biblical proverbs that illustrate both of these things well is found in Proverbs 26:4-5:

4 Do not answer a fool according to his folly,

or you yourself will be just like him.

5 Answer a fool according to his folly,

or he will be wise in his own eyes.

The first step is you are supposed to think: is it worth arguing in this situation?

The second step, when you’ve had multiple failed interactions with a person, is to think: is it ever worth arguing with them? If the person is a fool, then you just can’t win.

The third step is when you think like this: I notice that no-one ever argues with me for long. Is that because I’m always right, or because I’m a fool who refuses to lose an argument?

So when it comes to programming, you’re not just supposed to pick whichever of the conflicting proverbs suits what you wanted to do anyway, you’re supposed to recognise you might be about to do something silly, and reflect before you continue.

If it looks like you’re about to go against accumulated wisdom, you need to think about where the proverb came from, and the consequences of ignoring it.

For example, with “DRY”, you need to understand that it’s not about repetitive or boring code, but about embedding the same knowledge into a system in multiple places, and how this is a problem when you come to change something. WET, on the other hand, is about premature abstractions being more costly than duplication.

Once you’ve slowed down enough to think about it, you can work out which applies in your situation, and what you can do to mitigate the difficulties you might encounter if you choose to ignore the proverb – in other words, you can apply Chesterton’s Fence.