I just read an article that compared the crowd management techniques used in the stadium in ancient Pompeii to modern techniques, and while it’s an interesting read all by itself, and I do recommend you read it, I got to wondering about how similar ideas would apply to software design.

Build a bigger bathroom.

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.

In the meantime though, 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.”

Separate Queues from Promenades.

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.

Open Open Open!

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.

Build a Big Road

I think this mostly speaks to bandwidth and processor cycles and remembering that we are rarely so lucky as to have constant usage patterns.

Limit Corners

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 [entrancies piercing the banks of seats of a theater, amphitheater, or stadium] 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.

Limit Options

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 mp3 player 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.

Anxiety Control

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.

Nuceria vs. Pompeii

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.

Respect Personal Space

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.