Ad-hoc & Easy

There are two problems that current solutions have. One is that our conversations are ad-hoc, sometimes with people you've never met before and only have a fleeting connection to. Skype's contacts are not ad-hoc.

The other is that people need easy. Configuring IRC is hard. Heck, installing a damn program is hard for many people. Twitter and Facebook get close, but holding a decent conversation on Twitter is impossible, and Facebook is too autistic for people to use for ad-hoc communication. Besides, even signing up is often too hard. How many services do you not use because you would have needed to sign up first?

When I worked on Mahara, we used IRC. A few enthusiastic types joined us, but in large, IRC remains to this day inaccessable to many people. Not all users of Mahara are willing, or capable, of using it.

And when the Christchurch Earthquake hit this year, the response team that built eq.org.nz used Skype - which was by most accounts a terrible solution. Skype chat simply has too many bugs when you get to rooms of more than a few people - and we had over a hundred. Richard wrote a post-mortem that lays out the issues for communicating in a crisis.

Introducing buzzumi

So it's been my great privilege to have worked on a new service that addresses these problems. With Richard (a fantastic webapp developer who happens to be my cousin), we've been the tech team behind buzzumi, which just launched (he's lead, I'm wingman). It's a webapp that lets you create ad-hoc discussions - text chat, audio and video (A/V is completely optional). Your chat is accessible to anyone who can click on a link, without them logging in [3]. It's simple, beautiful, and lightning fast.

The chat host can set the background, and it changes for everyone in the chat. There's no limit on participants, and up to six people can use A/V at once [4]. It's great for team meetings, one on one discussions, and even webinars with hundreds of guests watching a broadcast. There's nothing to install (except flash), and no barrier to entry. You don't have to know the other participants, and when you're done, you can close the chat and never see them again.

Perhaps one of the coolest features is that you can make a chat have a fee for entry. buzzumi handles all of the payments for you. So you could hold a webinar on a topic you're an expert in, charge $50 to enter, and simply collect your profits when you're done (buzzumi takes a 10% cut).

Please Try It Out!

If you're in education, how could you use this for your school/university? If you're in disaster response, can we please ditch Skype for this? And if you know me from somewhere else, I'd love to hear your thoughts about it, technical or otherwise.

Give it a try, and let me know what you think! I have created a chat which I'll hang out in for a while as well, come by and say hello if you have a second.

ps: Get Your Game On is still rolling, we are busy running much of the summer football around Wellington.

1. Start with a Test Suite

Remember the goal is to go fast with confidence. If you're just going fast, you're simply speeding, and will soon become another statistic.

Okay, end of car analogy. However, you need to build confidence, which is what the test suite is for. Start there. You don't need to over-do it, but be smart. Start by ensuring it's easy to add tests, and then write relatively comprehensive tests for the critical flows in your application. What these are is entirely up to you - if you don't know them, maybe you had better start there :).

You should also set up a CI server, and get the tests running on every commit. If nothing else, this should enhance your existing development process.

2. Rig up Continuous Deployment to Staging

Staging, test, UAT, whatever you call these environments that aren't production - get continuous deployment working at least that far. These environments can be broken with relative inconsequence, so you can work with confidence initially. Over time, you should find their uptime improves, especially as your test suite begins to show its strength.

In particular, in this step, your aim is to put the test suite in the way of deployment. It should be impossible to deploy without a test run having completed successfully on the code being deployed.

Note that the presentation suggests that you employ a "Commit triggers tests, tests passing triggers deployment" tactic. This is a simplification. In larger teams, it may make more sense to work more like this: "tests are run every 15 minutes, with success resulting in deployment". This allows many commits to be made in one window (common for large teams), with the knowledge that anything you commit will take at worst 30 minutes to make it to production (assuming the tests pass).

3. The Management Gambit

You will know you've done the first two steps when the tech team thinks "this is working nicely all the way to staging - why not to production?". There's one final obstacle in your way - the fear of everyone outside the tech team.

On some level, management/clients are going to have to get comfortable with the idea of code being deployed without their approval, and often even without their knowledge. You can use presentations like mine to help here. Remember, if you can win over just one person, they can help sell the idea to everyone else.

At a base level, they most likely will fear the lack of control they will have. To combat this, tell them that you'll implement the system, but they have the right to demand change freezes - periods of time where you won't be allowed to deploy. They probably already have this right, but re-affirm it anyway.

This is false security for them. Martyn has a sign on his desk, which reads "Change Freeze (n): A time in which more changes are made to production than usual". When there are urgent problems, change freezes be damned - changes are made, and we all know it. The next time they have a change freeze, they'll ask for a change, and instead of flailing about you'll be able to make it with a smile. They'll never have another freeze again.

I also mentioned during the talk a USB rocket launcher for retaliating against people who break the build. Enjoy!

Being Prepared

From quake to functioning map took us a few hours - a commendable effort, made possible thanks to Ushahidi, their hosted Crowdmap product, and of course the efforts of everyone involved. However, I feel this was much too long.

Firstly, we were working in an emotionally charged, chaotic environment - one in which mistakes would have been easy to make. Second, we were given a lot more luck than we may have otherwise expected, thanks to the Ushahidi team co-operating with us over the migration away from Crowdmap, and the help of CrisisCommons in getting us started [2]. And third, during the first few hours, stuff.co.nz and NZHerald (the two major online news sources in NZ) both set up their own maps, and had it not been for our connections and their willingness to help, three competing maps could easily have sprung up, none of which would have been much help at all.

Spending hours setting up the site manually is the wrong way to do things, and we all know it. However, we can't predict disasters in advance. So it seems to me that we either need the ability to set up a site in minutes, or a "general" site prepared in advance, which can be adapted within minutes for whatever disaster is taking place.

Let's explore both options briefly. The ability to set a site up in minutes requires some prior planning, however it makes no assumptions about the nature of the disaster, and allows us to set up and tear down sites as we see fit. Disaster hits two cities? Just deploy two sites. During down time, as long as a minimal amount of maintenance is done, we can keep the process well oiled. Furthermore, we can develop "template" sites - one for earthquakes, one for tornadoes etc., and deploy the right "type" of site during a disaster, providing great agility.

Setting up a site (or sites) in advance has a different set of complications and benefits. A URL can be published in advance of any disaster, that everyone knows, so when a disaster hits more people know where to go (e.g. wellington.disaster.org.nz [3]). However, it may take more work to be able to re-configure the site for different disasters, as opposed to simply deploying a fresh site. And naturally, the site will need maintaining during the time between disasters, which could be many years.

The other aspect of being prepared, as alluded to here, is having data prepared. That doesn't just mean having categories prepared - that means having map data for everything of significance ready. Why should it take until a disaster for us to plot Wellington's ATM locations on a map? Why can't we prepare this data beforehand, ready for use the moment it's needed?

Improving the Tools

We made great strides towards improving Ushahidi for the task of disaster mapping on the eq.org.nz project. However, I fear that a lot of our good work hasn't made it as far as it could. The code sits (rots?) in a github repository, many of our changes having not made it anywhere near upstream - despite still being needed.

I've helped out with a couple of disasters since the quakes, and in each case, I found myself doing the same setup work, then fixing the same bugs, as we did previously. Clearly, pushing some fixes upstream would be a good start. However, the issues with using Ushahidi for crisis mapping run deeper than just a few fixes.

We made many changes that improved the usability of the map and homepage, the stability/scalability of the platform, and to streamline the workflows of people approving reports. We didn't push these changes upstream, and I'm reminded of this with every disaster has occurred since then. The eq.org.nz site really did finish as a much better product, but it's a height we haven't attained since.

To be clear, I'm not blaming anyone for this. People burned out, interest waned and we all had our lives to get back to. But I think it would be great if we could "close the loop". After all, you never know when it's you who will be needing the map...

Closing the Loop

I found out about the Standby Task Force after the Christchurch Quake. They're a network of "adhoc groups of tech-savy mapping volunteers that emerge around crises into a flexible, trained and prepared network ready to deploy." In other words, they're the eq.org.nz team, except larger, more organised, and with a global focus. When disaster strikes, if the locals ask for help, the SBTF are ready to respond, providing a map, volunteers and expertise to get things rolling. Now I think of it, they're a little like Internation Rescue (from Thunderbirds), in its infancy. No rocket ships I'm afraid ;), but a group of people willing and able to help in times of emergency.

Somehow, through a combination of my motivation to improve the tech for future disasters, and the prodding of George Chamales and Kirk Morris, I've fallen into the position of SBTF Tech Team Leader. My plan is to, as part of this team, work on both of the technical aspects outlined above. The goal: that anyone will be able to deploy a map ready to handle a disaster within minutes of it occuring.

I've donated some code from Get Your Game On to get started on a system for performing one-command. We're also planning on maintaining a branch of Ushahidi [4] optimised for crisis mapping, to which I hope we can apply many of our patches from eq.org.nz and other sources over time.

With this, I hope we can truly close the loop - so that when Wellington, or anywhere else, is struck by disaster, our response will be as good as it can be.

Final thoughts: I'm only focusing on the tech. There are clearly other issues we need to work through, not least the political ones. I hope next time to see a much closer relationship between government and such volunteer efforts, although it's not an issue I feel I can influence personally.