weblog.masukomi.org

He’s actually talking about the bathrooms and concession stands but there are
a couple applicable bits here: The bathrooms are an incredibly important part
of any stadium. They also have nothing to do with the core purpose of a
stadium. Keith recommends three things in regards to their creation:

1. Keep them separate from the main stadium because mixing them in just causes
   congestion and increases anxiety.
2. Make them big. In a stadium environment your bathrooms are generally
   accessed in waves. The average number of people who use it per minute may be
   quite load and lead you to think you don’t need big ones, but the usage
   pattern is anything but steady.
3. Make sure you have plenty of space to get to and from them for the same
   reason you need to make them big.

The software analogies are fairly obvious. Most applications have support
systems that are completely unrelated to the core function of the app. Lets
look at Last.fm for example. They’ve got an
underlying system(Audioscrobbler)
that manages the incoming data from peoples music apps. Without this Last.fm
wouldn’t work but nobody says “Oh i want to use Audioscrobbler.” Hell, most
people don’t even know what it is. No, people say “I want to see what the
people I know are listening to.” or, “I want to share my playlists with
people.” Last.fm just wants to show people lots of interesting music stuff so
that they can sell advertising and convince you to buy things on Amazon for
which they get a cut. If they could accomplish this without having to write
plugins for music apps or tons of bandwidth costs from people sending in track
data I’m sure they would. But, in the meantime Last.fm has to be careful that
there’s a big pipe between Audioscrobbler and the web site. It needs to be
separate because it’s NOT the core product and issues that effect one
shouldn’t have a negative impact on the other. They’ve also got to make sure
that the Audioscrobbler servers are big enough to handle the surges. If not
people will stop using the main site. They’ve also got to be easily
accessible. This means good APIs so that other people will find it easy to
implement and big pipes so that when the morning rush hits they’ll be up to
the challenge.

At Pompeii, he says, “they clearly planned for the rush that would
occur at the end of a spectacle. You had the same human needs”—to visit rest
rooms—“but the layout and design made the whole dynamic of moving to and from
much better.”

This is actually tied to the bathrooms and concessions, but the point is that
you don’t want the traffic that’s central to your app getting bogged down by
data that’s queued up for a completely different, but related, system. This
doesn’t just apply to bandwidth and cycles though. It also applies to design.
Break your functionality down into appropriately separated bits. You shouldn’t
have a method that handles moving objects around two sections of the system
when it’s much more sensible to have one for each.

Here’s a challenge: Look for
areas of Pompeii’s stadium where bottlenecks might occur, where the crowd could
overwhelm a space. Still says you won’t find them. Seats are at the optimum
viewing angle, and seating “packing densities are to comfort, not cost.”

Similarly it’s important when writing code to keep in mind that functionality
might expand beyond your original intent. Keep that in mind and you’ll not
have to worry about being straight-jacketed into convoluted or restrictive
pieces of code to implement new functionality. Make sure your code has room to
breathe.

Modern stadiums often
maintain the oval seating but then put blocky concourses around it. They also
use switchback walkways and stairs. All of that creates corners. Corners force
people to slow down and encourage congestion. Pompeii’s concourses were
elliptical; few corners exist to slow people down. Still says this also evened
out flow to the vomitories as people could, like liquid, choose the path of
least resistance easily without interrupting their pace.

To me this speaks to good APIs and good GUIs.
Ruby on Rails is all about minimizing
corners in the APIs. The goal is to make the process of developing a webapp a
simple easy flow. You don’t have to stop and deal with some complexity here,
or some thing unrelated to what you’re trying to work on. No, Rails lets you
just keep moving forward with your development, impeding you as little as
possible, and each successive version of the app has minimized more and more
corners.

When it comes to good GUIs you need to apply the same principle. Users
shouldn’t have to stop and do something only tangentially related to
accomplish their task. Consider where people are going and make it so that
they can get there with as few course changes as possible.

In crowd management, the
maxim called Braess’
paradox states that more options equals decreased performance. That is, if
you give people many routes to choose from, crowd traffic will slow down because
of indecisiveness and selfish behavior when choosing one of the paths.

The guys over at 37Signals have been
preaching this and implementing it to great success for years now. It’s
similar to limiting corners because each corner is work and when there’s work
people make a conscious or unconscious decision regarding whether or not it’s
worth the work. When we limit options we’re minimizing the number of decisions
a user has to make to accomplish their task, and as a result, we’re minimizing
corners. Users frequently request every conceivable option and configuration
control but when you actually give it to them they don’t want it. It would be
like an iPod with 37 switches 12 sliders and 4 knobs. Sure it would let you
get your music exactly how you wanted it but it would be too much of a pain in
the ass to use so you’d trash it and go buy an iPod.

I’d recommend checking out Getting
Real by the 37Signals guys if you haven’t already, because limiting
options and corners is central to the process they describe.

Still says facility
managers “can shift the behavior of a crowd. Good signage and lighting, for
example, will reduce anxiety. People need information before they approach the
crowd. If one person has to ask where their seat is, then 140 people have to
ask. Now there’s a backup and people are frustrated. Now those frustrated people
sense disorganization and start acting out. Others take that cue and the anxiety
feeds on itself. People say it’s the crowd’s fault. No. As the facility
managers, you shape the behavior.

In our world anxiety doesn’t grow into a stampede, it turns into bad word of
mouth and users who won’t use your software. So, make sure your users have all
the information they need to accomplish their tasks but don’t overwhelm them
with tons of docs. Imagine if you were at the stadium and had to read through
five paragraphs of signage just to figure out where to pee. Obviously you can
help reduce anxiety by limiting options and corners too.

During games between
bitter rivals Pompeii and neighboring Nuceria in A.D. 59, the historian Tacitus
writes of an altercation that “arose out of a trifling incident at a
gladiatorial show. During an exchange of taunts…abuse led to stone-throwing,
and then swords were drawn.”… This might seem to disprove Still’s notion of
best practices in ancient crowd control. To the contrary, Still says. “Think of
the fact they could have a sword fight in the stands, what that meant about how
they had very free movement in the stands. And because of the space, people
could cluster away from the small pockets of danger, preventing small incidents
from becoming bigger ones.” The violence, in other words, was not a stampede or
a crush. Today, nearly all crowd incidents affect the innocent, who simply can’t
escape.

We can learn a few lessons from this.

• Make sure that one user’s craziness can’t force itself onto others.
• Make sure your app can handle the fact that some people will come in
  carrying unexpected items (ideas of usage and/or data).
• Make sure your entire app doesn’t come crashing down when problems break out
  in one or more sections. Yeah, you won’t be able to use that one piece but
  maybe you should be able to use the other pieces without it.

In ancient Pompeii they made sure that everyone had the appropriate amount of
elbow-room in each section of the stadium. As developers we need to recognize
in advance which portions of the app will be working hardest and plan
accordingly. Mostly this speaks to optimization and scaling. Early
optimization is generally a bad idea but that doesn’t mean you should ignore
optimizing sections where it’s obvious you’ll need good performance and
if there’s a good chance you’ll need to spread some section of your app over
multiple boxes then you should plan for it from the start.