Perfect is the enemy of good
Voltaire
Programmers come up with rules constantly in an effort to make our products more resilient, the code easier to work with, or even to release. Sometimes these rules play well with each other but sometime these rules contradict. This creates a problem for the programmer — given a set of rules contradict each other, which one should the programmer follow?
This problem of conflicting rules is exacerbated when working with a group of other programmers on a common product. When making development decisions it is very easy to fall into the trap of violating at least one rule. Some software engineers make it their job of pointing each of these violations out and often, discussions will focus on how the group can rearrange code or decisions to ensure the violation is made right.
However; I have observed that this creates a new problem. Since programmers have so many rules that should be followed every decision is like taking a step in quicksand. Every choice is contested and one can quickly become discouraged. An experienced programmer learns to question every decision themselves. Ultimately this may come at the cost of value output for the business. We may be able to get around this issue by using a cognitive technique. Enter hypocrisy.
The authors of The Fundamentals of Software Architecture talk about how every architecture choice is a trade off. When you decide to move forward you are sacrificing something to gain something else. In that context, one can argue that the perfect product that adheres to all rules programmers create for themselves is simply too expensive to create. We are all constrained by time or money and it is our duty to deliver value to our customers.
Maybe the code base doesn’t adhere to a trend and maybe the code base does indeed have ugly code. It is hypocritical to say that, yes, this code base has these issues and maybe there are bugs that still need to be resolved, it is still shipping. Hypocrisy is allowing the group to make a trade off — deliver the code now to generate value for the business at the cost of generating tech debt.
The teams who ship are the teams who are best positioned to gain more. By using hypocrisy we can begin to undercut perfectionist conversations that get us into the trap of analysis paralysis.
Next time you are in a technical conversation remember to weigh the trade off of obtaining perfection versus shipping code.