Stuart Ainsworth

SCRUM, Source Control, and the SQL Server Developer (Part 2)

So my last post focused on the modifications my shop has made to our implementation of Scrum without a lot of details about how we manage our code changes. This post is intended to explain how we set up source control to support the scrum process.

Source control is one of those poorly-defined practices; it’s something we know that we should be doing as a developer, but it’s not always done as a DBA. In fact, I would guess that many shops that have DBA’s doing most of their reporting and data integration tasks don’t practice source control methods at all; if they do, it’s typically in the form of scripting out the entire database or relying on differential backups. Separating the data structure from the data itself is often difficult to do, so I am sure that many teams don’t do it at all.

We’re currently using Visual Studio for Team Systems with Team Foundation Server as our source control repository; it’s been a steep learning curve for those of us who came from a Visual SourceSafe background, and applying that knowledge to the unfamiliar context of a new UI (VSTS:DB Pro) and concept (source control for databases) has been more than challenging, particularly since we’ve adopted a new development method (Scrum) as well. It’s take a lot of discussion (sometimes quite heated) to get where we are today, especially since there’s not a lot of “best practices” discussion for source controlling SQL Server out there.

The biggest challenge has been the concept of branching and merging; TFS recognizes that you may have multiple development lines going on, especially among multiple developers. When do you split code out to work on it? When do you put it back together? How does this affect deployment of new features, vs. the release of patches to fix the currently deployed line of code?

For us, we decided to address our database source control thusly:

We set up the initial databases in source control in our Main branch. The Main branch is supposed to represent the heart of our code; it’s the final resting place of changes before they go to QA.
From Main, we branch off a line of code for each PBI (Product Backlog Item; see my first post) that we’re working on. If a PBI spans multiple databases, we include a copy of each database under that PBI. Our cookie trail in TFS looks something like this:

Main…Database1
Main…Database2
Development…PBI 1…Database1
Development…PBI 1…Database2
Development…PBI 2…Database1

Once a PBI is ready to be deployed, we merge the databases for that PBI back to their original sources; if another developer merges in their changes which would cause conflict, those conflicts have to be resolved before we allow the final merge (this means that if Dev1 working on PBI 1 has some changes that would affect Dev2 working on PBI 2, those changes are discovered at the second merge).
We also have a line of code that represents Productions deployment; at the beginning of each Sprint, we branch from the Main line into Production and then do a schema comparison with production to ensure that the Production line actually resembles Production. In case of a needed patch, we patch the production line, deploy it, and then merge those changes back into the Main line. If there are conflicts, we have to find them and resolve them.

There are some drawbacks; merging a patch into Main doesn’t always go smoothly, since we have to track down who is responsible for what changes. Documentation in the procs helps, but we need to do a better job (especially when those changes involve objects that are not easily commented; like tables). Furthermore, when it comes time to deploy from the Main branch, if QA decides that a feature isn’t ripe yet, then we have to do some legwork to back it out. All in all, however, it works, despite the bumps along the way.

I’d be interested in hearing how others are doing source control for their database scripts; please feel free to comment below.

SCRUM, Source Control and the SQL Server Developer (Part 1)

(If you’re just visiting me from SQLServerPedia, thanks for stopping by!)

I recently responded to TJay Belt’s post about his Release Management process, and thought it would be better to fully explain our development cycle here. Although I come from a DBA background, I currently work on the development side of the house in our enterprise. About 6 months ago, we made a decision to adopt Scrum as our development process, and for the most part, it has greatly simplified our release cycle. I’m planning on this being a two part post; this part will focus mostly on what Scrum is, and how we use it in our shop to release database changes, and part two will focus on how we use source control within the Scrum methodology.

You can read the Wikipedia article about Scrum, and it sums things up far better than I can; however, what I want to contribute to the discussion are some guidelines for implementing the scrum process. There are two basic goals to scrum: first, you want to increase visibility into the development process so that customers (the product users) know what to expect and when to expect it, and second, you want to organize your deliverables around measurable increments (sprints have daily scrums, which identify progress and impediments). It’s important to understand these two goals in order for you to understand why we implemented the rules we did. Please note that these are our rules as of this date, and they may change, and your shop is free to change them as you need.

The Sprint will last 4-5 weeks. Most scrums talk about Sprints lasting x number of days, but we broke it down into weeks because of the following constraints:
- We have certain processes that begin at the beginning of the month, and some that begin at the end of the month. We wanted to be sure that our Release Date always fell in the middle of the month, and
- We wanted to have a consistent day of release. We’re a 24x7x365 shop; for our business, most installation is best done in the middle of the week (so we can quickly identify any adverse affects).
We wanted to minimize the number of releases. Most issues can wait 4-5 weeks for complete development, even though the Product Users obviously want it NOW!!! To accomplish this, we had to deal with the issues of units of work, and emergency patching:
- If an issue is an emergency, and cannot wait until the end of the Sprint for release, we will release a patch on Wednesdays. In our model, patches are discouraged, but if they have to happen, they at least happen on the same day of the week as the regular sprint release. This ensures that everyone affected knows when patches may be implemented (and when to expect downtime).
- In the scrum model, a Product Backlog Item (PBI) is a prioritized unit of work; a Sprint Backlog Item (SBI) is a unit of work that is accomplished during the sprint. We enforce a hierarchy in our shop; PBI’s are composed of SBI’s. We do not release partial PBI’s; all of the child tasks (SBI’s) for a given Product Backlog Item MUST be completed before we release the code into production. If some set of SBI’s is required for a given release, we may split the PBI into two in order to accomplish this goal.

As a database developer, most of work is at the core of many of the changes; there are few PBI’s that do not involve some sort of change to the database. What we’ve noticed is that I’m often in demand at the beginning of the sprint, but my time consistently frees up toward the end; to help shift the burden a bit, we often stub out a dataset for the application (i.e., the app developers will dummy up a local dataset as opposed to making a stored proc). This is useful for two reasons; it delays their need of my services until later in the sprint, and it also defines what they want the output of a stored proc to look like.

In the second part of this article, I’ll discuss our source control arrangement and how it maps to the sprint.

2009-05-20 by Stuart Ainsworth Development SQLServerPedia Syndication 1

SQLSaturday #7: Birmingham, AL May 30, 2009

I’ve been so busy with all of my other projects at work that I’ve forgotten to really tout this. On May 30, I’ll be presenting at the Birmingham SQLSaturday (hosted by the Steel City SQL User Group). My talk is titled “Confessions of a Data integrator”, and will focus on dealing with other people’s database designs.

Over the last twelve years, I’ve built a career on pulling data from a variety of data sources, most of them which were poorly designed (according to the basic rules of normalization). From that experience, I’ve pulled together a set of principles for extracting data which I plan to share. This is a bit of challenge for me, because I’ve never actually written any of these rules of mine down 🙂

Anyway, if you can make it, please do; stop by and see me.

2009-05-17 by Stuart Ainsworth Conferences SQL 0

SQL Server & XML: links of interest

I’ve been working on a project recently that requires using XML in SQL Server, so I’ve been searching the web to find references. Books Online is unusually obtuse on this subject (the samples are sub-par for this complex subject), so I’ve been trying to find good examples of how it works. Here’s some of the better ones:

Passing lists to SQL Server 2005 with XML Parameters Jon Galloway gives a short and sweet example of shredding an XML variable into rows.

XQuery Inside SQL Server 2005 A longer set of examples using CROSS APPLY to associate XML data in a column to a value in a standard column. This is probably the most important query I needed, because we have a lot of XML values (config files) that are stored in a table; those config files are specific to particular clients.

SQL Server 2008 Books Online Here’s the basic data elements; again, the vocabulary is dense, but you at least need to know where it is.

Now, on to FLWOR (which I’m just beginning to study): Blooming FLWOR – An Introduction to the XQuery FLWOR Expression

2009-05-14 by Stuart Ainsworth SQL Server SQLServerPedia Syndication XML 0

Death by a thousand cuts…

This is has been an awful week; things have just not gone as planned from the get-go. I’m gonna run through several issues in this post, and perhaps someone will find some value in them; lessons learned may help others avoid the pain of my ways.

VSTS: DB Pro

This week, I’ve spent way too much time just trying to figure out how to use Visual Studio; I’ve mentioned in previous posts that I’m a database developer, but that I’ve spent most of my career working with the standard SQL Server DBA tools: Query Analyzer & Management Studio. When we migrated to TFS, my manager encouraged me to adopt VSTS:DB Pro as a method of developing, and I’ve put some real effort into learning how the system works. I’m slowly becoming accustomed to it, but there’s still some very quirky things that I’ve yet to figure out.

Issue 1: Logins. Whenever I import a database into a database project, I get a long list of errors because we have Windows accounts associated with users in the database; since those users don’t exist on my laptop, the project throws all kinds of ugly errors. Googling the error reveals very little information; the only method I’ve found to eliminate the errors is to drop the associated users and schemas, which of course, can lead to VERY BAD THINGS in deployment scripts. I’m sure there is a method to resolve it; I just haven’t found it yet.

Issue 2: The Silent Source Control Failure. Most of my projects involve references to vendor databases; we have a policy of not modifying vendor databases, so when I need to write a stored procedure that accesses data from a third-party source, I create a linked database that sits on the server beside the vendor database, and include my proc in there. I don’t touch their code, but am able to customize my queries to pull data. When setting up projects in VSTS:DB Pro, I usually make my custom database the primary project, and include a database reference to a project based on the vendor db. This usually works out OK, but I ran into an error yesterday where the project wizard would complete, but the project was unable to load. Nothing I did would fix it; I finally removed the vendor db from the solution, and was able to load my project (albeit with tons of errors because of the lack of references).

The problem? One of the stored procs in the vendor db has an extremely long name (nearly 100 characters); combined with the path to the workspace, the name of the file exceeds the 255 character limit for Windows file management. TFS apparently doesn’t know how to tell me that the file name is too long, so it just refuses to open. Try wasting 2 hours of precious development time tracking that down, and you can imagine how frustrating that is.

Haste makes waste.

A few months ago, we made a decision to adopt a version of Scrum to standardize our development processes; we’ve made up some of our rules along the way, and for the most part, we’ve done OK with it. However, the pressure to show progress and meet the needs of the organization means that sometimes I’ve made the wrong decision in my desire to please our Product Users. One case was today; one of our rules is that we a) strive to only deploy once a month (at the end of a sprint), and b) if we need to deploy an emergency patch, we only deploy on one day of the week (Wednesdays).

One of our users found an issue, and a production DBA researched it and made a recommendation for a relatively simple code change; I was out of the office Monday, so I only saw the recommendation on Tuesday. The issue was important, and the code looked good, so I thought I could get away with rolling it out today; unfortunately, I didn’t do due diligence on the code, and neglected to check for dependencies on that particular proc. We deployed my change today at 8:30 AM; by 3:30 PM, I was rolling it back. Luckily, the only side effect was that we generated a few extra tickets for our clients, but still, it was a painful experience.

The one thing I want to carry away from this experience is that as our system becomes increasingly complex, the less likely it is that a simple change can be made in less than a day. The code may be simple, but the context of the code in terms of surrounding processes SHOULD warrant time for thorough review. I need to quit reacting to the deemed urgency of the issue, and think about long-term stability instead.

Even the best deployments can have issues.

Overall, I think our deployment process works well, but even a good process can have points of failure. Even though we have several sets of eyes examining all of our code before it goes into production, things can still slip by. For example, at 3:45 this afternoon, I was informed that a stored procedure in production was not returning all of the data; the procedure pulls data from a third-party database, and makes certain assumptions about the nature of that data. In this case, we have a standard naming syntax for all of the devices we manage; ClientID, followed by a space, then device name (e.g., 999 Joe’s Server). The stored proc had a where clause that ended with LIKE ‘[0-9][0-9][0-9] %’; the missing row of data had a device name with the space omitted.

Now, it wasn’t entirely my fault because I had written the code to spec; however, I should have anticipated that the naming convention could be slightly off (and still be parseable; if they had a 2-digit client id, it would be a different story); in the end, our company looked bad to a client because of typo, and that’s not good. Easy to fix the code, but hard to regain the trust of the client.

Tomorrow WILL be a better day.

I’m not much for mumbo-jumbo, but I do believe that life is what you make of it. If I go back to work tomorrow and assume that it’s going to be a bad day, then I’ll probably be proven right. I’m changing my attitude as of this moment, and I choose to believe that the priority issue that I address tomorrow (while it may not be the issue I want to work on) will be the issue I was meant to work on.

2009-05-14 by Stuart Ainsworth SQL SQLServerPedia Syndication VSTS:DB 0

Educational opportunities a blooming….

Just in case you’re not following http://sqlsaturday.com, there’s been a few announcements of upcoming SQLSaturdays. I’d love to go to a few of these, but we’ll have to wait and see how the economy shakes out a bit.

SQLSaturday #7 – May 30, 2009 – Birmingham, AL. I’m still working on my slides for this one; if you show up, please come find me and say hi.
SQLSaturday #12 – June 6, 2009 – Portland, OR. I’d love to go to this one, but obviously Oregon’s a bit of a haul from the ATL (plus, see reason for not going to #14 below).
SQLSaturday #14 – June 6, 2009 – Pensacola, FL. My family’s leaving on a cruise on June 7th, and I’m very tempted to say “we could swing by Pensacola a day early…” Ain’t gonna happen.
SQLSaturday #16 – August 8, 2009 – Miramar, FL. South Florida will rock.

Of course, there’s lots of other development code camps going on; here’s a couple that I want to attend:

Codestock – The dev community in Knoxville, TN is an incredibly awesome bunch of people; it’s southern-fried hippy geek culture at its finest.
DevLink – Technically, devlink is not a code camp (they actually charge a substantial fee – a whopping $100), but they’re close enough that I feel comfortable placing them on this list.

You can find a much more complete list at http://codecampjukie.com.

2009-05-08 by Stuart Ainsworth Conferences SQLServerPedia Syndication 0

Gonna be some changes around here….

If you’ve been here recently, you may have noticed a new theme; I’m trying to clean up the look around here a bit. I’ve decided I want to be a little more proactive about my blogging, and decided that I wanted a new look to go with it. Why the sudden interest in blogging?

First, SQLSaturday is over, and I need a new challenge to keep me busy until the next one rolls around.

Second, I’ve noticed that I’ve gotten rather stale about doing anything technical related; I’m not challenging myself to learn something new, and that was the whole point of this blog in the first place.

Anyway, I hope you enjoy the new theme, but keep an eye out for some other minor changes around the bend.

Stu

2009-05-04 by Stuart Ainsworth Blogging is FUN! 0

Rube Goldberg would be proud…

This post is a bit of a rant; I spent the whole day trying to resolve a curious chain of events. Basically, I wasted a day of development troubleshooting something stupid; hopefully, others will learn from my mistakes, and avoid the pain and suffering I experienced.

It all started with SQL Server 2008; we’re looking at migrating to it sometime this year, and I finally begged the production guys into letting this developer get a copy of it installed on my machine. Seems to make sense, since I don’t know, I WRITE THE CODE THAT THEY RUN. (sorry, a bit tense). Anyhoo, I started the install. All was going well, apart from the unusual hiccup with my Logitech web cam. I eventually got it installed, started to play around with it, and then I noticed that I only had 1 GB of disk space free.

Sidebar: remember when 1GB was a HUGE amount of space? Unfortunately, it ain’t much now, and my laptop is starting to suffer from too-much-crapitis.

Realizing that I was running out of space, I made the extremely stupid decision to uninstall SQL Server 2005 from my hard drive and free up a few gig. SQL 2008 should be sufficient right? I do very little development on my local box (we have dev servers for that), so I thought I would be safe. How wrong I was. The uninstall took about 30 minutes, a reboot later, and I get bugged by Dan about an issue with one of the database projects I checked in using VSTS:Database Professional. I fire up Data Dude, and basically my laptop shot me the bird. Apparently, VSTS REQUIRES an installation of SQL Server 2005 to run; SQL 2008 won’t do.

Sidebar: I realize that there is a new version of VSTS:Database Professional that doesn’t have this requirement, but until it’s official, I can’t have it (company policy). Make it official, Microsoft, and you won’t get rants like these. I’m warning you! (insert mental picture of an ant shaking his fist at an elephant).

Since I had limited space to install, I chose to install SQL Server 2005 Express edition. All went well, until the installer required a version of MSXML 6, and then it puked. Why? Because Windows XP Service Pack 3 installs a higher version of MSXML 6 then SQL Server 2005 does, and the SQL Server 2005 can’t write over the newer version, but nor will it accept the newer version as valid. This is the computing equivalent of saying “I like cherry pie and I like whipped cream, but I don’t like cherry pie with whipped cream”. I couldn’t install SSE 2005 until I uninstalled MSXML 6, and I couldn’t uninstall MSXML 6 without uninstalling Windows XP SP3.

Sidebar: Insert mental picture of ant and elephant again, only this time the ant is banging his head on the desk and crying while the elephant leaves a large steaming deposit nearby; the elephant’s not cruel, just oblivious to the ant’s peril.

Luckily, I found this post at support.microsoft.com, describing the use of the Windows Installer CleanUp utility to remove MSXML 6, without uninstalling XP SP3. Dodged a bullet there, I thought to myself; instead, I stepped into a lawnmower blade. I got SQL 2005 Express installed, fired up VSTS:DB Pro, and realized that I HAD THE WRONG VERSION (missing service packs; I had version 611, VSTS:DB Pro needed 612). No big deal, right? I’ll run Windows Update, get the missing service packs (since I was now on an old version of MSXML 6 anyway); bad idea.

Apparently, there’s been a lot of patches since XP SP3 was released, including a Service Pack for SQL 2008 (the cog that started this pinwheel); 900 Meg of patches to download, which wouldn’t be such a big deal except for the fact that my company has my connection capped at 512K.

Sidebar: The ant has just realized that it’s not entirely the elephant’s fault. The queen ant has also made some strange policy decision that must be followed. However, it’s much easier to blame the elephant, because it’s lonely without a job or an ant hill. Stupid elephant; wise queen ant.

Anyway, at 3PM this afternoon (I clock out at 4PM), I was able to answer Dan’s question. Looking forward to another productive day tomorrow.

2009-04-30 by Stuart Ainsworth SQL Server SQLServerPedia Syndication VSTS:DB 2

Reflections on my comfort zone

Spoke to a good friend today; a guy I haven’t seen in several years, but we exchange emails pretty regularly. He’s been having a rough time this year: he lost his job earlier this year, and has been trying to find work to keep him afloat while he revamps his career. He mentioned to me today that he was moving back to our hometown so that his kids would be near family while he gets thing sorted out.

Home is a comfort zone, and it’s the place to go when things are bad; while I support my friend, I did give him one piece of advice: don’t settle there. It’s not a bad place to live, and I have lots of friends who are very happy to live there, but there’s a difference between making the decision to live someplace because you like the benefits (home, a small town life) and settling for a life because you’ve run into a wall elsewhere. This guy and I always had the dream of leaving town; granted, we both thought life was going to be different than it turned out, but at least we both managed to get that part right. We moved out, onward, and upward. It’s OK to go back to visit, but don’t stay unless you’re sure you know why you’ve decided to stay.

As I was thinking about this, I realized how much I have settled in my own career. I like my current job (lots of benefits), but I’ve gotten bored with the grind lately. I’ve stopped challenging myself to learn something new, and have settled into the “same old, same old” because it’s easier that way. While I continue to be productive, I haven’t grown professionally as a developer, and that’s not a good place to stay. It’s OK to visit, but not OK to settle.

So today, I seize the day. I go back to the lists of things to do, and I start ripping through them and challenge myself to learn something new.

2009-04-29 by Stuart Ainsworth Blogging is FUN! Education 2

So you wanna host a SQLSaturday? Here’s my tale….

This is going to be a long post; definitely the longest I’ve written in a while, and probably longer than anything I’ve ever written. So long, in fact, that I’ve toyed with the idea of breaking it into separate chunks. However, I decided to keep it as one piece because I felt like someone out there may want to print it out, and I thought it would be easier if it were one post. Before I get too deep with this, I have a few caveats; first, I am not an expert on SQLSaturday, nor am I the authority. I’ve done one, and while I feel like it went well, there is always room for improvement. If you really want to get to know about SQLSaturday, you need to contact Andy Warren and get a copy of his infamous checklists on things to accomplish. I just wanted to write out some of my experiences and ideas in the spirit of sharing. Second, my experiences may not jibe with your experiences, so don’t try to emulate me too closely. I just happened to be in the right place at the right time for a lot of this, and you are probably in a different place (and most certainly a different time).

Anyway, on with the list; first, a little background. SQLSaturday #13 was held April 25, 20009, at the Alpharetta, GA offices of Microsoft. I first started talking about a SQLSaturday in September of 2008, and began actively planning it in January, 2009. I did have a lot of emotional support (and opportunities to bounce ideas around) from the leadership of AtlantaMDF (as well as Andy Warren), but I did most of the logistical legwork myself. I say this not to brag, but so that you understand how it came together. Being the primary planner for this event was helpful to me because it let me understand where I could do better with delegation in the planning stages; I do need to say that on the day of the actual show, I had a huge team of volunteers who went above and beyond anything I could have asked. I may have planned the attack; the volunteers carried it out.

Speaking of that, let’s talk about planning for a SQL Saturday:

1. General principals

One thing I wish I had done a better job of was to keep asking myself the question: “How does this build the local SQL Server community?” I think we had a great event, with great speakers, and great attendance, but if we didn’t build up the community, we wasted a lot of effort on a single day. The point of a SQLSaturday (or any user-driven community development event) is that the local technical community should be built up AFTER the event is over. Connections need to be made, networking should increase, new speakers should be encouraged to grow. We accomplished some of that with SQLSaturday #13 (more on that later), but more could have been done. Ideas include:

promote the heck out of the sponsoring user group; make sure that every attendee walks away knowing who the user group is, when they meet, where they meet, and how to contact them.
include Twitter/Facebook/LinkedIn directories as part of the event registration
have chalk-talks, ask the experts, or coding contests throughout the event to encourage people to share, and not just sit and listen.

2. Delegate, but have a single decision maker

There are several roles that need to be fulfilled, both before the event and during the event; I’ll try to detail some of these, but always remember that you need a single decision maker at the top of the food chain. During the event, when things happen, it’s far better to have someone make a quick (and accurate) decision than it is to try and negotiate or look to find someone who knows how it’s supposed to be handled. In other words, if there’s a question about how prizes should be handled, and your prize master doesn’t know, they should go straight to the top. So here’s my short list of roles, including a description and a time frame for their duties:

Event Coordinator: The event coordinator is the person in charge; they delegate authority to everyone else. They need to be in on the process from the beginning of the planning stages, and they need to be familiar with all of the issues associated with implementing the show. Where is the event going to be? What date will it be? What are you going to serve for lunch? Are you going to have a lunch fee or not?

Sponsor Wrangler: This role is the money role; they’re responsible for two things: 1) find sponsors, and 2) keep the sponsors happy. You keep sponsors happy by making sure that they feel like they’re getting a good value for their sponsorship (ideas on that later). Sponsor Wranglers are also responsible for making sure that the sponsors keep up their responsibilities; your sponsors will have other obligations, and just like you can let something slip if you’re not careful, they can too. Also remember that some sponsors will want to donate goods instead of financial support; it’s up to you to decide if that’s OK, but if you accept goods, the Sponsor Wrangler needs to make sure that those goods arrive in time for the event.

Speaker Wrangler: You gotta have talent for the SQLSaturday, and the Speaker Wrangler role lines that talent up. Make sure you pay attention to point 1 above; you want to bring in enough talent to have a successful show, but you also want to foster community. The Speaker Wrangler needs to seek out a mix of experienced and new talent, as well as try to get local and regional (or even national talent). This role also needs to think about things like the speaker dinner, the speaker shirts, and getting the slides and code from the speakers after the event is over.

Volunteer Wrangler: No matter how many people you have helping you plan the event, you need a small army of volunteers to actually run it. The Volunteer Wrangler needs to coordinate with the Event Coordinator to find people to do things like help set up, stuff event bags, place signage for the event, manage the registration desk, collect feedback forms, and handle prize distributions. I actually had a couple of wonderful volunteers who stepped up the day of the event to handle event registrations and be my prize manager; I told them what I wanted, and they did it.

Note that you can have multiple people fulfilling one or more of these roles; you just need to have these roles fulfilled.

3. Event day issues.

Here’s a list of stuff to think about:

Always have a health plan. Midway through the first session, a volunteer found me and asked “do we know where the first aid kit is?” I shifted from relief to panic in at lightning speed. Turns out someone had a minor cut, it was really nothing, but I didn’t know where the first aid kit was. You should also know where the local emergency rooms are, as well as the address of the facility in case you have to call 911.
Pack a tackle box of supplies. You’ll need paper, tape, scissors. You may also want to keep a printer handy in case you need to print badges on the fly.
Have a plan for non-registered “showups”. See the bit about printing badges on the fly.
Even with a lunch fee, some people won’t show up. I kept thinking we were gonna have 100% attendance since people ad already paid for this, but we still only pulled about 85%. That’s kind of sad, given that we ha to turn away people from the pre-registration because of fire code. It really meant we needed a larger facility.
You have to buy lunches for everyone; over-order veggie meals, and figure out something to do with the extras. You can send them home with attendees or donate them to the local fire department. Just have a plan, cause you WILL have leftovers (see the point above about no-shows). Make sure that you have a list of who gets a veggie meal at registration, and stick to that list (some meat-eaters change their mind).
If you have to change rooms between sessions, make sure you have plenty of time to do so. We had a large room that could be separated into 3 rooms; we had plenty of time to make the change before the lunch speaker, but I didn’t leave enough time after the lunch speaker to change configurations. We made up the time, but something to think about in future events.
Don’t expect to attend more than 1 session. I like learning, and you probably do to. However, one of the sacrifices of putting on a conference like this is that you don’t really get to attend the conference. Spend your time networking with the speakers and sponsors who aren’t speaking. Hang out with the attendees; just don’t plan on attending too many sessions. DO PICK ONE, however, and go to it. You deserve it.
Eat well before the conference. You probably won’t have time to do so during the conference, unless you eat BEFORE the lunch break. Our case, sandwiches were delivered at 11:30 for a 12:00 lunch; I should have grabbed one out of the delivery guy’s hand and eaten it then. I tried to eat during the lunch break, but was busy resolving issues.
Get a room. If you live more than 10 minutes away from the conference location, you probably ought to consider getting a hotel room nearby the night before. Get as much sleep as you can before the conference, because you’re gonna be bone-weary the night after it’s over. I live 30 miles away from where we had our conference, and I almost didn’t make it home without falling asleep.
Schedule space by the speaker, not the topic. I tried to have smaller rooms for more advanced topics, and leave the larger rooms for beginning topics. I had a popular speaker giving an advanced topic in a small room, and it was overflowing. People like to hear good teachers speak on something even if the topic may be more advanced than the audience.
Try to fill every block of your schedule with something to do. I had a couple of gaps late in the day because I thought there would be some attrition. I was wrong, and ended up with overloaded sessions.

I think that’s it for now; I’ve still got a lot left to do in the coming days, but I think this should suffice for a write-up for now. If you’re thinking about hosting a SQLSaturday, do it. It’s a great experience, and it’s an incredible way to connect with the database professionals in your area. If I come up with more ideas, I’ll write an addendum to this post.

2009-04-28 by Stuart Ainsworth Conferences SQLServerPedia Syndication 1