I just got back from Las Vegas. From the second you land there, you can smell the alcohol in the air. It’s also probably the only place i know where you can gamble while waiting in baggage claim….and people do!

At any rate, we gambled, we lost, we left. Statistically, that’s about right so no hard feelings.

One thing that I did notice while there was how queues are serviced. I’m not normally that observant, but it was pretty easy considering that:

One particular incident involved me standing in line at the MGM Grand Concierge to pick up some show tickets. This was how the line looked:

Queue Per Server

Each server / concierge (the dots) has its own queue of people. It this a good solution? Of course not! This is the perfect situation that breeds line-choice-remorse. It’s that well known phenomenon which occurs after choosing a line – you soon realize the line next to you is faster while you’re stuck behind a guy that is buying tickets for twenty five people, a restaurant reservation, maps for all of Nevada, a limousine, some shoe string, an igloo, and a towel. At least that is what it seemed like at the time.

In short, having a Queue Per Server doesn’t account for variation. Assuming that each person has the same priority, they join the lines at random intervals, and each person takes a random amount of time to service, this is the perfect recipe for some queues to be blocked up for long periods of time while other queues might be empty. It also doesn’t serve people in the order they joined.

Luckily, most of the other lines in Las Vegas were like this:

Single Queue, Multiple Servers

While these lines might look longer, they are actually more efficient. These queues have one line which includes all the people in the order joined, and multiple servers each taking a person from the front of the queue. Making the same assumptions as the previous example, this method is actually more resistant to variation. If one person takes a much longer time, only one server will be blocked and the queue will continue to flow. In addition, it’s better for your mental health.

The perfect example of this is the Taxi line at the airport. The line was literally hundreds of people and if you didn’t know better you’d think it was going to take hours to get a taxi to your hotel. In reality it took 10 minutes. We were literally walking non-stop in the line. They had a system where 15 taxis would drive in and predetermined spots and drive off with the soon-to-be poor vacationers. Pure awesomeness.

These decisions happen in software development too, especially in multi-threaded environments and Message Queues. I wonder where they got the idea from….

ORM solutions have really made a huge impact on software development with relational databases. It’s pretty much expected from any modern object oriented language to have a built-in ORM solution and/or multiple 3rd party implementations of one.

You could even write a pretty impressive list of benefits of ORMs like productivity, avoidance of vendor lock-in (except DB specific ORMs), and maintenance. But in spite of all this, I do find that ORMs have a very real and prevalent hidden cost:

ORMs set the bar too low for who gets to write data access code

You might have seen this happen, or you may been that person once, but time and again i’ve seen how the lack of understanding of what’s happening “behind the scenes” cause very painful performance, stability, and design issues: 1-n problems, fetching too much data, ignoring batch updates, etc. to name just a few common ones.

ORMs take the discipline of fine-tuned and precise database interaction and takes a huge warm dump on it.

Now don’t be mistaken, the elite can and will use ORMs in the best possible way and in all the right places, but let’s be honest about the majority. I’ve seen the blank stare with eyes glazed when I asked a developer why they wrote 3 nested loops to find a specific value of the child of the child of a mapped ORM entity instead of just writing a specific query for it. Or why they retrieved and iterated over all 5 million items to set the same value of of the same field instead of writing an update statement.

Somehow people assume that writing specific queries for specific cases when using an ORM is an admission of defeat when they can easily just traverse the object graph and call their setters and getters. It all comes crashing down though when you have enough data.

In the end using ORMs properly requires even more knowledge and ability and it should be entrusted to those people who can get it right.

Those of you have passed this hurdle should congratulate yourselves. There aren’t many of you.