Test driven development is a nice try at a solution to confirmation bias. You start off by being wrong about your code and then you work on fixing that and get

Test driven development is a nice try at a solution to confirmation bias. You start off by being wrong about your code and then you work on fixing that and get all the tests to pass. But that too is prone to confirmation bias on a larger scale. Sometimes you get into a 'test-driven dictatorship', where the amount of broken tests dictate what changes are ok and which would just be too time consuming to introduce. That's how you start gluing pieces together which have nothing in common, just so that you don't break too many tests in the process. So , no silver bullet, but still a step in the right direction I guess. Confirmation bias is also at play especially when we have an overly complicate architecture. Because it's so complicated, it must be smart so any requirement can be made to fit into the architecture. I've learned over the years to consider myself guilty without trial for the confirmation bias sin and the solution is to always keep architecture primitive and simple. Minimal dependencies. Minimal voodoo. Simple, boring code. When I feel that I've done something 'smart', I know I'm building sand castles and am trying to prove something that I shouldn't.