So, here you go, the reasons why I decided that being in Seattle was the right decision for PASS, in no particular order of importance, just what comes to mind.

Location

I think Seattle is a great location in terms of travel as it works very well for our friends in Asia/Pac. I found it interesting that people would comment about how the cost for them to go to Seattle would increase but not one person has mentioned that the cost for someone coming from Australia or India would find it cheaper (not to mention faster). Perhaps that means that the cost is the same for someone to go from Melbourne to Orlando as it would to Seattle? Certainly it will be faster and easier for them to get to Seattle.

No matter what location we choose, someone will end up paying more to attend, and it will take longer for them to get there. I’m currently on the East Coast and would love for the Summit to be closer to me, but I also recognize that what makes things easier for me makes things more difficult for others. About the only neutral location I can think of for everyone to share the burden of travel would be Antartica, which might be perfect because we could get Bill Gates to be our keynote speaker.

Money

PASS is not flush with cash these days. Most everything we do needs to be “budget-neutral”, as we simply do not have piles of cash laying around to throw at ideas to hope something sticks. Our budget is mostly funded by the Summit, so we need to make certain that the Summit continues to generate some revenue, otherwise we operate at a loss. For a non-profit, operating at a loss is not a good thing. If you do that for too long then you will simply cease to exist. You can see our financial situation at the Governance page (you need to login to view this section).

So, the safe choice is to stay in a location that we know “works” for us. We know how to hold a Summit in Seattle that allows for us to have a chance of breaking even and possibly even make a profit that we can then reinvest back into the community. Except for the Mayans, we cannot predict the future, and yet we need to book our conferences years in advance. I have no idea what things will be like in 2012, so I err on the side of caution and felt that Seattle was the wisest choice at this time.

Branding

I want PASS to become “the” SQL Server event, and I want that event to be in the same location every year. I also want the Summit to have over 10,000 attendees each year. And guess what? Seattle cannot hold a conference of that size. Given what we are as a community right now, Seattle is a fine location for us to build a brand around. For where I want us to be, we will be need to relocate, and I would love for that day to come as soon as possible. But we aren’t there yet.

Microsoft

I am certain you are all aware that without Microsoft we wouldn’t be here, right? We are the Professional Association for SQL Server. We are dedicated to promoting SQL Server. So, what is wrong with making it easier for their employees to attend out Summit?

I read a few comments about how Microsoft is able to send employees to other conferences, such as TechEd. Does any of those other conferences get hundreds of dedicated SQL Server employees? I am sure TechEd has hundreds of Microsoft employees, but that is across a variety of products and not focused on just SQL Server.

Also, keep this fact in the back of your mind: the Microsoft attendees are paying to attend. We move the Summit, we lose their attendance, and our revenues go down. In case you missed it earlier, I’ll repeat this: we are not flush with cash these days. Having those attendees is a boost to our bottom line right now, and not one I want to walk away from so easily.

SQL Saturdays

PASS is looking to start some smaller events. The acquisition of SQL Saturday is a step in that direction. Another step would be hosting events that are in between a SQL Saturday and a full Summit. We haven’t worked out the logistics but one thing we do know is that we want to keep the Summit as the main event. The regional events along with the SQL Saturdays are events that would be ways for us to promote the main Summit.

There you go, my reasons for why I voted the way I did. I am willing to discuss this through UStream tonight. If enough (say 7-10) people tell me that they want to set aside 15-20 minutes to hear me speak about the reasons I listed above, then I’ll set up the broadcast stream to start at about 7:15PM and we can let the healing begin.

This whole situation is making me less interested in supporting the organization. As a relative newcomer to PASS and having never attended a Summit, I’m turned off by the “come talk to Microsoft employees” stance. I’d rather them say come and talk to (or sing Karaoke with?) cool guys like Brent Ozar and others in the community who deal with real world issues day to day.

The arguments for keeping the Summit in Seattle largely boiled down to cost & access to Microsoft. Cost has been beat about the face & neck by me & others, and I can’t add anything else even marginally intelligent to the conversation, so I’ll shut up on that. Microsoft. Yeah, having access to Microsoft makes the Summit pretty cool (not to mention useful, a couple of my favorite sessions were from Microsoft presenters). PASS stands for the Professional Association of SQL Server users. The summit is produced by PASS in order to meet it’s own goals which are ”dedicated to supporting, educating, and promoting the Microsoft SQL Server community.” (Yeah, silly me, I go and read the organization’s web site).

So here’s my comment. Is the community PASS is trying to support, educate and promote better represented by a bunch of Microsoft developers, or, to quote Aaron, “Brent Ozar and others in the community who deal with real world issues day to day?”

And, lest I take an inappropriate beating, I’m neither knocking Microsoft developers, nor saying that they’re not a part of the community. My job and, to a small degree, my life, wouldn’t be the same without those people. I just want to make sure any rocks tossed my way are thrown for the right reasons.

There have been a fair few forums questions in recent months asking for help in removing index scans, loop joins, sorts or other, presumed, slow query operators. There have been just as many asking how to replace a subquery with a join or a join with a subquery or similar aspects of a query usually for performance reasons.

The first question that I have to ask when looking at requests like that is “Why?”

Why is removing a particular query operator the goal? Why is changing a where clause predicate the goal? If it’s to make the query faster, has the query been examined and has it been confirmed that query operator or predicate really is the problem?

The title of this post refers to a comment I’ve seen again and again in blogs or articles about front-end development. “Premature optimisation is the root of all evils.” It’s true in the database field as well.

While optimisation is very important in database development, trying to optimise queries without any idea where the problem with the query is, or even if the query is a problem at all is about as effective in fixing a database performance problem as using a shotgun from 100 meters is in killing mosquitoes. If you hit the problem, it’s by shear luck and nothing else.

There’s two sides to this problem.

The first aspect of this is, during development, spending time on optimising a query (or stored procedure) without any idea whether or not the query is inefficient and no idea whether or not the changes made make any improvement or not.

Firstly this is a waste of time that could be better spent developing other queries. Second it creates an incorrect impression that the queries have been optimised when in fact nothing of the sort has been done.

The second aspect when, with a production database that is performing badly, queries are modified almost at random in an attempt to fix the performance problem quickly.

This almost never works. It wastes time fixing stuff that very likely isn’t broken in the first place all the while the database performance deteriorates and management curses SQL Server as ‘nonscalable’

So, what is the right approach for the above two scenarios?

1. Don’t optimise queries without knowing if they need it.
2. Don’t optimise queries without knowing if they need it. ¹

New development

When writing queries and stored procedures they need to be tested against a representative data set on a server with representative workload and their performance characteristics evaluated to see if they are acceptable. If the query’s performance characteristics are acceptable, then that query requires no optimisation²

This doesn’t mean write bad code and push it to production. It means write good, solid code, following accepted coding standards, ensure that it runs acceptably against production-volumes of data, and do not spend hours or days trying to get it running a couple of milliseconds faster.

And if the query doesn’t perform acceptable, identify the problematic portion and fix that, don’t flail around rewriting bits of the query in the hope that the problem will magically go away.

The execution plan is the primary tool here, along with the output of Statistics IO.

Fixing existing code

When evaluating existing databases with know performance problems, limit the performance tuning to queries that really are performing badly and need optimisation. It’s often true that fixing the top 5-10 worst performing queries will have massive effects in overall system performance, far more than tuning twice that number of queries that aren’t really a problem.

The best tool for finding which queries really are the worst offenders is SQL Trace.

When looking at queries that are a problem, identify the portions that are inefficient and target attempts at optimisation towards those problems.

In conclusion

Measure Twice.
Optimise if necessary.

(1) No, that wasn’t a typo.

(2) At that time. Later changes to schema or data volume may require existing queries to be revised.

For more details on exactly how to identify problematic queries, refer to the series I wrote at Simple Talk last year.

Meetings are like bad blocking queries – they tie up precious resources and stop other people from getting work done.  Today, let’s talk about how to optimize both of ‘em.

Minutes of typical corporate meeting

Do Your Homework Ahead of Time

If you’re going to hold a meeting, build the list of decisions or tasks you want to accomplish during the meeting.  Send out that list ahead of time before you schedule the meeting, and you might be pleasantly surprised at how much work gets done without the meeting, because:

• Some tasks really only need one person to accomplish them
• Some decisions are only made by one executive (without input)
• Some research can’t be done during a meeting
• Some people will do just about anything (including extra work) to avoid meetings

When designing your SQL Server transactions, put together an agenda.  Out of the list of tasks, try to move everything out of the transaction.  Can you run some of the queries ahead of time before BEGIN TRAN?  If so, that lessens the number of locks you need for your transaction, and makes your transaction run faster.  When examining each query in the transaction, ask yourself:

• If this data changed between the time I queried it and the time the transaction committed, would it be a problem?  If you’re fetching the customer’s bank balance before you update it, that would be bad.  If, however, you’re checking the date the customer’s account opened, it probably isn’t going to change while the transaction runs.  That might be a good candidate to move out of the transaction.
• If I had to rollback the transaction, would this query be affected?  If it’s just a select, the answer is probably not – but your mileage may vary.

This is especially important for transactions that run frequently, like hundreds of times per minute.  In one engagement, we found a common transaction to update an employee’s details.  In the beginning, it checked the employee’s supervisor’s status before updating the employee record.  By moving that query out of the transaction and doing the work ahead of time, we cut the transaction execution time by over 90% without affecting the integrity of the query.

Minimize the Number of Objects Involved

Know why most meetings and transactions are like an OK Go video?  There’s way too many things involved.

And if you think that machine is complicated, think for a second about the process of filming it.  Everything had to work perfectly, the camera had to smoothly move throughout the entire operation, the guys had to move from one position to the next to hit their mark in time, and the whole thing is choreographed in a way that you don’t see the guys moving from spot to spot.  If you like this, check out their marching band version or their famous treadmill video, and note that they’re all done in one very long take with no camera changes.  (The Rube Goldberg one does have a cut in it, though.)

The more people involved in a meeting, the tougher scheduling gets, and the more people sit around twiddling their thumbs during the meeting.  If you only need someone for 5 minutes of the 60-minute meeting, try to accomplish that goal ahead of time and free up 55 minutes of their time.

When designing your SQL transactions, be acutely aware of every table you’re inviting to the party.  SQL Server has to schedule these objects because you’re not the only one who wants to use them.  The less locks you incur, the faster your transaction can get in and get out.

Have Less Meetings (and Transactions)

Do you really need to tie up multiple resources at the exact same time in order to get your work done?

Or are you just taking the lazy, selfish approach and grabbing lots of resources just because you can?

Coworkers and tables seem like easy resources to commandeer at a moment’s notice because you don’t pay the price initially.  As your work piles up, though, performance suffers.  Making the right call ahead of time pays off in the long run.

Tuning SQL Server Transactions – and Meetings is a post from: Brent Ozar - Too Much Information.
If you'd like to quote this content on other sites, please read how to use my blog's content.

Meetings are like bad blocking queries – they tie up precious resources and stop other people from getting work done.  Today, let’s talk about how to optimize both of ‘em.

Minutes of typical corporate meeting

Do Your Homework Ahead of Time

If you’re going to hold a meeting, build the list of decisions or tasks you want to accomplish during the meeting.  Send out that list ahead of time before you schedule the meeting, and you might be pleasantly surprised at how much work gets done without the meeting, because:

• Some tasks really only need one person to accomplish them
• Some decisions are only made by one executive (without input)
• Some research can’t be done during a meeting
• Some people will do just about anything (including extra work) to avoid meetings

When designing your SQL Server transactions, put together an agenda.  Out of the list of tasks, try to move everything out of the transaction.  Can you run some of the queries ahead of time before BEGIN TRAN?  If so, that lessens the number of locks you need for your transaction, and makes your transaction run faster.  When examining each query in the transaction, ask yourself:

• If this data changed between the time I queried it and the time the transaction committed, would it be a problem?  If you’re fetching the customer’s bank balance before you update it, that would be bad.  If, however, you’re checking the date the customer’s account opened, it probably isn’t going to change while the transaction runs.  That might be a good candidate to move out of the transaction.
• If I had to rollback the transaction, would this query be affected?  If it’s just a select, the answer is probably not – but your mileage may vary.

This is especially important for transactions that run frequently, like hundreds of times per minute.  In one engagement, we found a common transaction to update an employee’s details.  In the beginning, it checked the employee’s supervisor’s status before updating the employee record.  By moving that query out of the transaction and doing the work ahead of time, we cut the transaction execution time by over 90% without affecting the integrity of the query.

Minimize the Number of Objects Involved

Know why most meetings and transactions are like an OK Go video?  There’s way too many things involved.

And if you think that machine is complicated, think for a second about the process of filming it.  Everything had to work perfectly, the camera had to smoothly move throughout the entire operation, the guys had to move from one position to the next to hit their mark in time, and the whole thing is choreographed in a way that you don’t see the guys moving from spot to spot.  If you like this, check out their marching band version or their famous treadmill video, and note that they’re all done in one very long take with no camera changes.  (The Rube Goldberg one does have a cut in it, though.)

The more people involved in a meeting, the tougher scheduling gets, and the more people sit around twiddling their thumbs during the meeting.  If you only need someone for 5 minutes of the 60-minute meeting, try to accomplish that goal ahead of time and free up 55 minutes of their time.

When designing your SQL transactions, be acutely aware of every table you’re inviting to the party.  SQL Server has to schedule these objects because you’re not the only one who wants to use them.  The less locks you incur, the faster your transaction can get in and get out.

Have Less Meetings (and Transactions)

Do you really need to tie up multiple resources at the exact same time in order to get your work done?

Or are you just taking the lazy, selfish approach and grabbing lots of resources just because you can?

Coworkers and tables seem like easy resources to commandeer at a moment’s notice because you don’t pay the price initially.  As your work piles up, though, performance suffers.  Making the right call ahead of time pays off in the long run.

Tuning SQL Server Transactions – and Meetings is a post from: Brent Ozar - Too Much Information.
If you'd like to quote this content on other sites, please read how to use my blog's content.

Server Virtualization

Storage for the DBA

SQL Server Service Broker in the Real World

It was great presenting this weekend.

Denny

If I am counting right, it looks like 26 separate blog posts were sent in for this month’s T-SQL Tuesday “IO, IO, It’s Off To Disk We Go”

I am still in the process of digesting them all but wanted to at least start the roundup post and at least do a quick scan of each entry, if not read it all. So far it is looking like a lot of great posts that all are worth re-reading. I might even try printing with the option to print all linked articles (never used it before) and have a closer look at these posts on IO.

Thanks for participating! If I somehow missed a post, please leave a comment and I’ll update the roundup and tweet the update out. My late night double check looked like none were missed.

First Time Participants

In no particular order give a big welcome to the T-SQL Tuesday party to the following bloggers who (as near as I can tell) contributed to their first T-SQL Tuesday:

Paul Randal talked about the behind the scenes goings on of a DMV we should all, hopefully, be familiar with – sys.dm_db_index_physical_stats. He relives his “younger” days and talks about where the “WITH FAST” option came from in the older DBCC SHOWCONTIG (Guess who wrote it?)

Michael Zilberstein explores perfmon, io counters and RAID levels in capacity planning. A good read with a good reminder at the end.

Glenn Allen Berry shared some scripts from his impressive (and well known) arsenal of T-SQL scripts to help us detect our IO pressure in SQL Server 2008. Great queries to help see if you are suffering from IO issues or not.

Robert Davis showed us a way to tell if our temporary objects are being stored on disk or in memory. I haven’t had a chance to play with the scripts he shares but it is on my short list of things to play with this week .

Kendal Van Dyke blogged about a topic I was fortunate enough to watch him present on this past weekend at SQL Saturday #33 –> Solid State Drives. This is the start of a new series he is starting, so I suggest you subscribe to his blog in your favorite reader to keep up with his posts. Solid states are here, getting better and we’ll be using the more and more each year.

Jeremiah Peschka went someplace else Great forray into a different Io altogether. Check it out and you’ll see what I mean.

Brent Ozar graced T-SQL Tuesday with his presence through a post about his findings with some Fusion IO drives he got his hands on for testing. Neat stuff but be sure to read about his caveats at the end. The technology is still being ironed out and he discusses some of the risks I have heard from others when it comes to some of the SSD technologies. Still may very well apply to some of your workloads and environments.

Gethyn Ellis took a walk down recent memory lane and gave us some good reminders from his walk. Sometimes it takes an “oops” to learn some key lessons and it’s even better when those lessons are on a test server as Gethyn’s was. I’ll be adding his blog to my feed reader (which in turn means my large blog roll) and I’ll be checking out more posts from him.

Remus Rusanu fit a post about large Service Broker Queues into the theme. He talked about some of the issues affecting them and reminds us that good database maintenance must include queue maintenance in environments with Service Broker.

Brian Henderson works for EMC and likes to blog about storage topics. He posts a link to a document a colleague of his wrote about SQL Server consolidation options. Interesting perspective.

Nicholas Cain Reminded us about the benefit of splitting files and filegroups onto separate spindles. Shows a good way to see what the hogs are with the DMVs. I will be adding this blogger to my blogroll also.

Merrill Aldrich shares some great lessons he picked up while doing a really large storage implementation. He worked with a new EMC symmetrix SAN with some SSDs on board. He got some nice results and his lessons should serve as reminders to all of us.

Stefan Bauer Gave us a blog post as part of an ongoing series he had on Disk Performance. In this post he covers some concepts around some of the performance monitor counters one could look at when analyzing SQL Performance. He also created a poll asking about the type of IO folks use (SAN, Local Disk, iSCSI, etc).

Pinal Dave Joined the T-SQL Tuesday fray (yay!) with a post about Covering Indexes and talks about where and how they can be helpful. He includes a good reminder in his disclaimer – covering indexes are not a one stop shop for all problems. You need to consider all of your workload when looking at indexes.

Denny Cherry is one of the people (like Paul Randal and Kendal Van Dyke, among others) who would make this their first T-SQL Tuesday with this topic. I wasn’t let down. Denny is just as much into storage as he is SQL (maybe even more, Denny?). This post helps show us how to find out where our disk bottlenecks are and how to go about troubleshooting at each area (SQL, Windows, Array)

Experienced T-SQL Tuesday Contributors

Again, in no particular order (just the order I clicked on them in the browser tabs I opened to read all the posts), here are the contributions from the folks who have participated in prior T-SQL Tuesdays:

Brad Schulz – If you’ve read a T-SQL Tuesday roundup before, I don’t have to say anything else. So I lied, I said no particular order but I had to put this one first. It is a long winding read but worth every minute. He takes us on a recursive journey through some CTEs.

.sETC emos hguorht yenruoj evisrucer a no su sekat eH .etunim yreve htrow tub daer gnidniw gnol a si tI .tsrif eno siht tup ot dah I tub redro ralucitrap on dias I ,deil I oS .esle gnihtyna yas ot evah t’nod I ,erofeb pudnuor yadseuT LQS-T a daer ev’uoy fI – zluhcS darB

Jason Brimhall reminds us that reducing the IO cost of a query is a worthwhile exercise. He uses a fun example to illustrate this to us. Check out his post and go hunt for the higher IO queries in your own environment. You can do it!

Sankar Reddy started off with a post about log blocks and log block checksums. Not to be outdone (by himself?) he posted a second post about a very important concept, Forwarded Records. Are you suffering from the ill effects of forwarded records? Check out his post and find out.

Aaron Nelson eeked in a bit past the deadline but I let him in with the couple hours of grace period. He was busy the past couple weeks preparing for his multiple sessions at SQL Saturday 33, I’m sure. He combined two themes and posted about an interesting troubleshooting journey and some lessons he learned along the way.

Kalen Delaney agrees with some of the other posters that looking at IO Statistics is a useful tool. Yet with one convincing and simple example, she shows us that they aren’t so useful in isolation these days. I use IO Statistics often when tuning but I also look at the big picture. If you tune to IO only, you can get caught up in trying to tune to lower reads at the cost of CPU or Duration – don’t

Michael Swart goes to the other side of the coin a bit. He talks about his own experiences and that tuning to IO is one of the best ways he has seen to improve query performance. I think if you take his advice, cross apply some of Kalen’s and Rob’s advice you’ll do just fine. I agree with Michael, in the majority of cases I come across, reducing the reads reduces the duration. Just be cautious like Kalen said and don’t go overboard like Rob said.

Rob Farley also weighed in on the whole query tuning to IO question. He showed an example involving string manipulation where more IOs did not equal less duration. In fact the opposite happened. Rob was also the host of T-SQL 003 on Relationships. Check out his roundup to see the posts for that one.

Michael Cole’s article should give you pause if you are presuming your use of Transparent Data Encryption is encrypting your Filestream data. Read his post and see why it isn’t, the picture makes it clear.

John Dunleavy gives us a great overview of RAID levels. What they are and some thoughts around each of them and their application to SQL Server.

Aaron Bertrand has had a great post series on Bad Habits to kick. He added a smorgasbord of bad IO practices to avoid in this installment. He starts off with his thoughts on the points raised by Kalen, Michael and Rob above when he reminds us that Ignoring IO in queries is a bad habit to kick.

Phew!

That was a lot of summarizing. Some really great posts and ensuing discussions from this one. There are actually a few that I’ll be printing out for coworkers to peruse. Some made me laugh, none made me cry. Thanks again to Adam Machanic for thinking up and organizing this concept! It is a lot of fun and I am looking forward to finding out who is hosting next month’s! If you want to participate I suggest you look at the #tsql2sday twitter search stream. If the next organizer doesn’t tweet, I am sure others will when they find out about the topic and dates. You don’t even need twitter to search for the stream. Just click the link. Even better? Just subscribe to the RSS feed for that one search tag here. You will only see new tweets that mention #tsql2sday.

I didn’t get a chance to finish my draft and submit it but it was heading out along the same lines of tune to reads so it was done by some great folks already anyway

Thanks again for participating, feel free to leave any comments about any of the posts or my comments below or on the original posts (or both).

We're planning a big road trip, you and I. We're going somewhere on vacation.  Here's what we've decided so far: we're taking my van, the SQLbus. We're going somewhere warm, we're taking your friend Steve, and we're splitting all the costs three ways.  Now, given this plan, how successful do you think we're going to be at achieving a decent vacation?  Nobody's even talked about specifically where we're headed - do we even agree on what "warm" means?? Nobody's talked about supplies, where or how we're sleeping and eating - campgrounds? motel? B&B? - the direction we're headed, how long we're staying, how much we're willing to spend, etc etc etc. 

With a vacation like that, you're going to head out in a random direction; drive around for four times longer than you want to in THE most boring, backwater, ugly places possible; spend TEN times what you wanted to, and get next to no value out of it; and argue with your roadmates the whole way through.

This, my friend, is how software is developed and sold in shops all over the world every day.  Make no mistake: there are shops that do it up right, with requirements, tech specs, and solid code. May their days be fruitful and their nights free of support calls.
  But we're not preaching to those shops. We're preaching to the poor lost souls who wander, nearly directionless, through the deep mists of scope creep.

Okay, okay, enough waxing poetic.

Without clear directions from the business owners, you can't create clear tech specs, without which you can't create a system that works. In a shop that works without real requirements, everyone is used to coding lonely.  A revolutionary idea like gathering and documenting business rules will most likely meet with a lot of resistance.  Even if it doesn't, getting real requirements is something of an art form. You can't just send the BA an email to say "We need your requirements".  You have to sit down in a room with the business folk and developers, talk it out, write it down, poke holes in the use cases.  As you move through the development lifecycle, you'll have to revisit and update those requirements.

This stuff isn't fun, which is why nobody does it.  But while you can just hit the road with a friend and a credit card, you can't pin the success of your business on the planning methodology of a college road trip.

Happy days,
Jen McCown
http://www.MidnightDBA.com

P.S. Yes, I know I should've photoshopped the image to read "Code Trip", but gimme a break...it's not my strong suit, and it's past midnight!

SQL Server 2008 Auditing Feature
SQL Server 2008 Audit Change Group

I’ve been playing around with SQL Server Audit for over a year now, but I have spent more time on it during the past six weeks. So much time, in fact, that I have submitted a talk for SQL Saturday #39 in New York City on April 24th. The talk will be titled SQL Server 2008 Audit, and I will give an overview of how to use the feature, review the various options, and even try to answer questions. So if you are in NYC on the 24th, stop by for a free day of training.

I get why they’re doing this. Microsoft really will commit more resources to an event that is in their back yard. I get it. I also understand, that those of us who consider the PASS Summit a big part of our “community” are actually in the minority. Most people attending the Summit aren’t involved in the community, aren’t interested in networking, and go to the conference to learn something and then go back to their hotel room. They want to see Microsoft developers, not community members. I understand. I also know that the excellent support team provided through the management company is also headquartered out there. We might see fewer of them at the conference, and those few will cost more to fly in. I get it.

But…

With the economy shrinking, and no end in sight, budgets are getting tightened. Travel expenses are being examined closely where I work and justification for a trip is more difficult than it was previously. Cutting a few corners here & there, including reducing the cost of a plane flight,  might make a difference. For example, doing a quick search on Travelocity, no details, accepting defaults, meeting half-way, in Dallas, would cost $216 instead of $399. That’s almost $200 in savings. Even if Rushabh is right and we’d have to increase the cost, let’s say $150/attendee, that’s still offset by the flight.

Still, those are savings at the margins, would that offset it enough to prevent people from travelling? Maybe, some people. But, there’s also the flight itself to consider. Not everyone is Gail Shaw, prepared to cross continents, oceans, raging rivers, burning deserts, and French strike lines to get to the Summit. For some people, that hike out to Seattle, ignore the cost, Microsoft, the community, is too much. Would moving it to Atlanta or Dallas or wherever guarantee a larger percentage of attendee’s? Nope, probably not, but I’ll bet you you’d see a different set of attendee’s and I’ll bet you the attendance wouldn’t drop. Because remember, it’s not just the flying time or the travel costs or the time away from work (yay). It’s time away from the family. Based on the results of the survey, 800 (51%) of the 1500 plus think a short flight is very or somewhat important, where as only about 380 (25%) thought it wasn’t. The vast majority of people responding to the survey are in the Eastern & Central time zones (585 & 458 compared to 331 in the Western zone). I could actually be wrong about the number of attendees.

And let’s just mention, Microsoft is holding some sort of get together in June. It seems to be fairly well attended by Microsoft people and, oh, look at that, it’s in New Orleans, not Seattle. I guess it is possible to get some Microsoft involvement in other places if Microsoft wants to.

I’m not on the board, so it’s easy for me to snipe from the sidelines, but based on the noise level, and the fact that 588 people thought having a conference on the east coast would make it more likely that they would attend, with only 405 making it less likely, and the fact that that number goes up to 639 more likely if the Summit was in the center of the country, I’m not alone in thinking that the PASS Community Summit should move around a bit more than we’ve been doing lately.

On another note, the release of the survey results was… poorly handled. The board, probably for good reasons, tends to play things very close to the vest. I think, at least in this case, too close. I appreciate the need to keep valuable information away from the competition. However, since this is a community organization, and one that is largely run by volunteers, I think the board really ought to err on too much communication instead of too little.

Finally, assuming anyone has made it this far, I want to thank the board and Rushabh for releasing this information. I think explaining how they made their decision and providing the basis for that in the results is absolutely the right thing to do. Did it apparently, or even evidently, require poking from people outside the board? Maybe, but they still did it and deserve the credit for taking the right action.

That’s it. End of the pointless, wandering diatribe. Go about your lives citizens. Hopefully, I’ll get another session or two accepted this year and I’ll see you all Seattle (again).