I was reading an article commenting on the brouhaha over the new requirements for how frequently women ought to get mammograms. I’m not a doctor or a scientist and I really don’t feel qualified to pass judgment on this topic for any number of reasons. The reason I bring it up, and not to start a fight, is because of one statement in the article caught my attention, “Another bias is the anchoring effect, the tendency to be overly influenced by any initially proposed number.”
The reason this “anchoring effect” was so interesting is because I had recently been involved in a very minor bit of revelation about a particular number around SQL Server; 1000 pages. This is the number that Microsoft has long suggested as the minimum number of pages that an index should have before you worry about defragmenting that index: http://technet.microsoft.com/en-us/library/cc966523.aspx. While presenting a session at the PASS Summit on using dynamic management objects as part of performance tuning, the question came up about how many pages would I say was the minimum. I mentioned Microsoft’s number and disagreed with it. A tweet went out from Jenn McCown (1/2 of the Midnight DBA) in the audience referencing my disagreement. Paul Randal tweeted back, “Oh, I made that number up.” Want to talk about dragging the anchor. Subsequently Paul explained where the number came from, and it’s not really made up. It’s a measure, a number that needed to be provided as guidance because, frankly, we don’t all know as much as Paul Randal. We need to have numbers upon which we can base our judgments for what’s good or bad in our servers.
Reading on to other sources about the whole mammogram issue, brought me to a pretty harsh discussion about the degree that women can take responsibility for their own health care based on knowledge. Again, I’m not trying to get into this fight, but it’s this idea that you either trust a number and follow it blindly, or begin to apply your own knowledge that I find fascinating. Back on databases and development, firmly and finally, I know that I’ve done both things. I have taken, completely as written, without questioning or investigating, measurements that have proven to be incomplete or even wrong. I’ve also taken the time and trouble to understand where measurements came from and what they applied to so that I could, with my own knowledge and experience, judge whether or not that number was accurate and applicable in my situation. While it’s more time consuming, obviously you would want to do this for every measure and rule, but you’re not going to be able to. At some point, probably frequently, you’re going to take it on face value that some measure, like 1000 pages, is correct because of the source of the data. Just don’t be upset when someone else questions that value because they’ve taken the time & trouble to investigate it.
The Scary DBA Podcasts
The podcast feeds are available at sqlservercentral.mevio.com. You can also follow Grant Fritchey on Twitter:
or now on iTunes!
- Windows Media Podcast - 20.5MB WMV
- iPod Video Podcast - 14.8MB MP4
- MP3 Audio Podcast - 3.5MB MP3
Today's podcast features music by Wakamojo. Support this band at http://www.myspace.com/wakamojo.
I really appreciate and value feedback on the podcasts. Let us know what you like, don't like, or even send in ideas for the show. If you'd like to comment, post something here. The boss will be sure to read it.
