Every once in a while someone brings up the subject of developer bias. This usually happens in the context of a conversation about software verification. How do we verify the software does what we need it to do?
By developer bias, these individuals are referring to their perception of some universal law that developers can’t ensure the software actually works. That for some reason, because developers created it, they’re biased and shouldn’t be left alone to verify it.
These individuals swear they’ve been burned repeatedly by developers missing important things when testing the software. And I believe them. I just disagree with their diagnosis, and as such I think their solutions are misguided.
Whenever someone claims someone else is incapable of ensuring the quality of their work, I’m skeptical. If a developer can’t ensure the quality of their work, how can they even work at all? The same is true of anyone that does work in any profession.
My skepticism leads me to dig deeper to understand the real cause of the perceived developer bias. In the majority of cases described as developer bias, I’ve noticed a common denominator. The developers were given marching orders, without any understanding of what those marching orders were meant to accomplish.
Naturally, anyone given marching orders, can only do their best to follow the orders. And to follow the orders as they understood them. The only thing an individual can do is verify they followed the orders as instructed.
There’s a gap though, between the marching orders and what the marching orders were meant to accomplish. Marching orders are simply inputs to the process. The impact on the organization is the outcome. It’s the impact that’s desired, the inputs are irrelevant so long as the outcome is obtained.
The larger the gap, the greater the perceived “developer bias.” Even worse, if the marching orders are incapable of accomplishing the desired outcome.
Because of this gap, the individuals responsible for giving marching orders are the only ones that can verify the result lines up with what they had in mind.
Ironically, when things don’t align, the misalignment is occasionally attributed to the mythical developer bias. Not, “Were the developers given the perspective to validate the desired outcome? Was there a gap?”
I think it’s important to step back whenever someone suggests developer bias and look for other problems. Perhaps, developers are rushed and aren’t given the time to do a good job. In fact, I often find this in concert with delegating marching orders, causing a boat load of problems.
There’s no such thing as a developer bias, it’s just an excuse to not dig deeper. Do people make mistakes? Yes. Is this bias? No.
The best way to avoid the mythical developer bias is to make sure developers understand what the software should enable the organization to accomplish. Let them come up with their own marching orders. Hold them accountable to results, not a TODO list.