Make Technical Decisions Easily With This One Trick

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

This dog knows more science than I do
This dog knows more science than I do

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.

Previous Post
Amazon EC2 Dedicated Hosts: Much Cheaper SQL Server Licensing
Next Post
AlwaysOn AG Databases Need Bigger Log Files

12 Comments. Leave new

  • Brett C. ("C" is for "curious")
    October 7, 2015 10:16 am

    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. 😀

  • 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.

  • 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.


Leave a Reply

Your email address will not be published. Required fields are marked *

Fill out this field
Fill out this field
Please enter a valid email address.