Decisions are emotional, right? Brent loves Sanka and I love Postum. We fight about it all the time. But when we wanted to settle the debate once and for all, we engineered a test to figure out who was right. You can do the same thing to take the personal investment out of technical decisions at work.
Check Yourself at the Door
The first thing you need to remember is that your opinions are just as valid everyone else involved. You need to move those aside and be ready to be wrong.
If the other people involved don’t want to play along, just tell them “Heck, I’d be happy to be wrong because I’ll learn something.” It’s not a bet or a contest, you’re just offering up your willingness to be wrong. Being wrong is great, especially when it’s your turn to be right later on.
Test, Test, Test
The next step to making that decision is to figure out a test. This test has to depend on your different opinions. The purpose of this test is to get your opinions out of the conversation.
Doing this correctly is really hard. You need to figure out:
- What are both sides saying?
- Which metrics will prove both points?
- What won’t prove anyone’s points?
- What’s the fastest way to test both options?
- What’s a realistic scale to for testing?
- What’s the worst that could happen if either side is right?
- What’s the worst that could happen if either side is wrong?
- If you can only run one test, which test should you run?
Hey, You Said This Was Easy!
All of this sounds like a lot of work. It turns out being factually right is just as much work as being factually wrong. If you really want to make sure that you’re choosing the right solution to a problem you need to figure out which option is the most right way to solve the problem – both solutions could be good, but one just might be better. The only way to get to proof is to test everything.
The next time there’s an argument on your team, or between two teams, figure out the best way to test each side’s ideas instead of spending your time arguing about which solution is the best.
Of course, you could always just fight in the parking lot like school kids. I hear that works well, too.
12 Comments. Leave new
Good post. The key, in my opinion, is to “check yourself at the door”. Though, that tends to be the biggest hurdle in arguments. Both sides have to truly want to know what the “right” answer is, no matter who is proved right or wrong.
Also, you neglected to tell us the results of the Sanka vs Postum test. Inquiring minds want to know. 😀
We were both wrong – both Sanka and Postum are foul.
Heh heh heh!
And thus you prove your humanity; you passed the test.
Heh, I cold have told you that without opening jars or brewing. Then again, I rate all coffee as foul, so perhaps I’m not qualified to speak of it.
Maybe that could be part of a robotic Turing test: is the robot smart enough to NOT make something like Sanka when asked to.
Hence the first rule of robotics: A robot must not harm a human being. 😉
Hi Brent,
Given that statistical sampling is likely the best way to resolve the age old question: “which coffee is better”…
How about setup several different coffee pots at SQL Interestion on the Tuesday morning in Las Vegas, 10/27, and sample the opinion of the DBAs attending the conference and publish the results.
Maybe add Starbucks, Dunkin Donuts and Tim Hortons to the coffee options for the atendees to sample.
At least we could expect a better cup of coffee on the first day of the conference than what is provided by the hotel.
See you in a few weeks.
When arguing Antivirus software – European Institute for Computer Antivirus Research (EICAR) and Computer Antivirus Research Organization (CARO) has a test file one can download and run.
i liked this post–i’d be interested to hear more about any real life (non-coffee) situation(s) which may’ve inspired it.
This advice is way too sensible. Seriously, data-driven decision making, scientific method and empirical process is totally overrated. Give me superstition, bias and emotional arguments any day.
Deal!
/me sets your bushes on fire because of your cheese purchasing decisions. Also, witches.
You left off a key part of making any decision in a production envrionment – “How will I explain this to my boss if it goes south”. Key question to ask.
That should be part of your testing. If you aren’t considering failure outcomes while you’re testing potential solutions, then you should change how you test.
I didn’t leave it off, I just assumed you guys knew that you should be doing that.