I’ve heard tell of a social experiment conducted with monkeys. It may or may not be apocryphal, but it illustrates an interesting point. So, here goes.
Primates and Conformity
A group of monkeys inhabited a large enclosure, which included a platform in the middle, accessible by a ladder. For the experiment, their keepers set a banana on the platform, but with a catch. Anytime a monkey would climb to the platform, the action would trigger a mechanism that sprayed the entire cage with freezing cold water.
The smarter monkeys quickly figured out the correlation and actively sought to prevent their cohorts from triggering the spray. Anytime a monkey attempted to climb the ladder, they would stop it and beat it up a bit by way of teaching a lesson. But the experiment wasn’t finished.
Once the behavior had been established, they began swapping out monkeys. When a newcomer arrived on the scene, he would go for the banana, not knowing the social rules of the cage. The monkeys would quickly teach him, though. This continued until they had rotated out all original monkeys. The monkeys in the cage would beat up the newcomers even though they had never experienced the actual negative consequences.
Now before you think to yourself, “stupid monkeys,” ask yourself how much better you’d fare. This video shows that humans have the same instincts as our primate cousins.
Static Analysis and Conformity
You might find yourself wondering why I told you this story. What does it have to do with software tooling and static analysis?
Well, I find that teams tend to exhibit two common anti-patterns when it comes to static analysis. Most prominently, they tune out warnings without due diligence. After that, I most frequently see them blindly implement the suggestions.
I tend to follow two rules when it comes to my interaction with static analysis tooling.
- Never implement a suggested fix without knowing what makes it a fix.
- Never ignore a suggested fix without understanding what makes it a fix.
You syllogism buffs out there have, no doubt, condensed this to a single rule. Anytime you encounter a suggested fix you don’t understand, go learn about it.
Once you understand it, you can implement the fix or ignore the suggestion with eyes wide open. In software design/architecture, we deal with few clear cut rules and endless trade-offs. But you can’t speak intelligently about the trade-offs without knowing the theory behind them.
Toward that end, I’d like to facilitate that warning for some CodeIt.Right rules today. Hopefully this helps you leverage your tooling to its full benefit.