Don't Think of an Elephant

I recently came across a scenario that I've experienced a few times with developers and I think it's worth writing about.

Sometimes when working with developers, we don't actually know what their biases are in relation to the work they have produced. Their brain is a black box and we don't understand what part of the requirements they understood, what prompted the solution they came up with, did they even write the code at all? A million questions spring to mind.

Sometimes, their bias is too easy to spot and too hard to ignore. Sometimes, they're telling you the problem by telling you where NOT to look. I like to use the "don't think of an elephant" analogy. When someone says don't think of something, you ignore the "don't" part and do it anyway.

I had a "handover" with a developer, where they literally said don't look inside the code, just look at the output of the code.

First of all, I decide where I'm looking, not the person who developed the code (or no code in this case). Sure, it can be useful to have a developer walk me through what they have done, but telling a tester to ignore any part of a system will instantly raise questions. Secondly, you're telling me to look away from all of the juicy bits. The confusing variable names, the broken SQL queries, the half finished logic app steps that are still there for some reason — these are the places I will always look if I can. In this case, there was a logic app with multiple http requests, calls to databases, parsing of JSON files and it was rife with complexity.

What this developer is saying is that they think their software is perfect (even though they said it wasn't a simple task) unless the output says otherwise. Inputs and outputs are very useful, but so are intermittent issues, performance issues, static analysis of the app itself, requirements, conversations, notes taken, the list goes on. Maybe they built a similar thing a million times, but you haven't tested it once.

Should we look into these things, anyway? Yes, I would consider that a responsible thing to do.

The lesson here is that when someone tells you to NOT do something, think about what that actually means, and do it anyway.