I recently asked a semi-rhetorical question on Twitter about health insurance in the USA. Specifically, it seems deeply weird to me that health insurance is tied in with employment. I mean, your employer doesn’t subsidize your homeowner’s, auto, or renter’s insurance, so why health insurance? Someone answered that this was an end-run around salary caps and restrictions that just kind of stuck around. This rang a bell, and I looked it up. Here’s an explanation that details how caps on wages during WWII were circumvented by offering this perk and making it tax deductible, and so a long, nonsensical tradition was born, established, and worked into our culture to a degree where everyone thinks, “that’s just the way things work.”
Many people respond to hearing questions of “why do we do this, anyway,” with something like, “hey, yeah, that’s a good question!” Once it’s pointed out to them, they recognize that perhaps an entrenched practice is worth questioning. Others balk at the notion and prefer doing things that are traditional, well, just because we’ve always done it that way. There seems to be something about human nature that finds ritual deeply comforting even when the original reasoning behind it has long expired. White dresses on wedding days, “God bless you” after sneezes, using signatures to indicate official permission, and many more are things that we simply do because it’s what we know, and if someone asked you “why,” you’d probably say, “huh, I don’t know.”
In this manner, software engineering resembles life. Within a group, things that originally had some purpose, reasonable or misguided, eventually become part of some unquestioned routine. I’ve seen shops where everyone was forced to use the same diff tool, where try-catch blocks were required in every single method, where every class had to implement IDisposable, and more, for reasons no one could remember. Obviously, this isn’t good. In life, tradition probably has an anthropologically stabilizing role about which I won’t speculate here, but in a software group, there’s really no upside.
Accordingly, I don’t want to team up with people that blindly follow cargo cult processes. It’s bad for the team. But who do I want on a team? It isn’t just people that are willing to forgo routines and rituals when they’re called into question and evaluated. I want people that think to do the questioning in the first place.
Don’t get me wrong. I’m not looking for iconoclasts that question everything whether or not there’s reason to question it or that rail against everything that others want to do. I’m looking for people that take no assumptions on faith and are constantly using data and objective metrics to reevaluate the validity of everything that they’re doing, even when those things are regarded as “no-brainers.” I want people that get creative when solving problems, expanding their thinking beyond obvious approaches and into the realm of saying “what if we could do it without doing this thing that we ‘have’ to do?”
It’s this kind of thinking that gave rise to NoSQL; what if a relational database weren’t required for every application? It’s this kind of thinking that turned the internet from a way to view documents into an application medium; what if there were applications that didn’t require CDs and installers? It’s this kind of thinking that changes the world, in software and in life. I want people on my team that wonder why their employer pays for their insurance, anyway.