Mar 26 2010

SMS Saves Lives

(2nd in the series “Superpowers and Science Fiction: How Mobile Devices Can Change the World“)

Text messages sent via SMS can reach their destination even when a cell network is too overloaded for phone calls to work. This knowledge can make the difference between life and death.

When Haiti was struck by a devastating earthquake in January 2010, buildings collapsed and trapped people in the rubble. Some had mobile phones, but were unable to call for help. Cell phone towers had power, thanks to diesel generators at the tower sites, but the phone network was overwhelmed by the number of people trying to make phone calls. Yet people were still able to send text messages, even posting to Twitter via SMS, pleading for help to free them from the rubble.

How is that possible?

Text messages are very short. SMS stands for “Short Message Service” – each message is limited to 160 characters. Compared to the amount of data sent for a voice call, this is practically nothing. Furthermore, SMS messages are sent on the same control channel that a phone uses to stay in touch with the nearest cell tower. The phone and cell tower frequently exchange packets of data to determine when the phone has moved to another cell tower’s area. Unlike a phone call, text messages do not need to be received at exactly the same time they are sent, and the receiver doesn’t even need to be in a coverage area when the message is sent. SMS uses a “store and forward” protocol that allows message delivery to be delayed until the receiver comes back into coverage. This provides an additional layer of reliability to ensure that messages reach their destination.

Almost every mobile phone has the ability to send text messages, but the same can’t be said for phone owners. If there are people in your life who have never sent a text message, encourage them to figure it out. Take the time to help them if necessary. Be the first person to exchange messages with them. It could save their lives. At the very least, it could give them peace of mind to verify that you are safe in the event of an earthquake, wildfire, or other disaster.

Mar 19 2010

Superpowers and Science Fiction: How Mobile Devices Can Change the World

I gave a talk recently at BarCamp San Diego entitled “Superpowers and Science Fiction: How Mobile Devices Can Change the World”. There was a ton of material packed into one half hour, which I’ll be unpacking in a series of blog posts.

The event itself was an “unconference“, which is essentially a format for crowdsourcing the sharing of interesting ideas and information. Just like wikis and blogs provide a decentralized way for voices to be heard on the internet, an unconference provides an unfiltered forum for sharing ideas in person. It’s not completely decentralized – a small core group of people arranges a venue, gets donations from sponsors, and promotes the event. However, there is no process of submitting abstracts for approval and creating a schedule of talks ahead of time. Attendees are encouraged to come prepared to talk or give demonstrations. At the beginning of the weekend, there is an empty board on the wall where attendees can sign up for a time slot in one of the available rooms. There is no filtering, but the aggregate feedback of the crowd provides its own kind of direction. It’s not unusual for presentations and informal conversations to influence the content of sessions later in the weekend and at subsequent BarCamp events. The unconference phenomenon started in the technology community, but it has spread to other communities including real estate, government, and crisis response. Unconferences share the core values of decentralization and democratization that have been critical to the social success of the internet. I believe these same values will be at heart of innovative developments that use mobile developments to harness the power of communities and large collections of individuals.

You might have noticed that I use the term “mobile device” rather than mobile phone, smartphone, or superphone. That’s because I find the ability to make and receive phone calls one of the least interesting features of these devices. They can help you to save lives, topple governments, and get free beer. They can also interrupt you with automated sales pitches from companies trying to scam you. See what I mean? I know I’m not the only one with this perspective, since Linus Torvalds (inventor of the Linux operating system) recently expressed a similar opinion. There is a vast selection of applications and accessories available for mobile devices. That is in addition to the increasingly long list of features embedded into many of these devices: email clients, web browsers, GPS receivers, compasses, and even the humble clock. Take a second to think about the implications of everybody carrying a timepiece that is continuously kept accurate. Future generations will hear the phrase “synchronize your watches” in an old movie and wonder what that means.

The camera and microphone are two especially interesting components of mobile devices. They are the eyes and ears of mobile applications. The camera enables applications to recognize book covers, logos, landmarks, and other images – even without barcodes. The microphone allows people to interact naturally with applications through spoken words. Combined with GPS for location and compass for orientation, this provides mobile devices with an unprecedented awareness of our surroundings. We have only begun to tap into the potential for using these devices to augment our senses and abilities in everyday life.

Here are the slides from my presentation, if you want a sneak peek:

Jun 7 2009

Google Wave – not just for distributed collaboration

The buzz around Google Wave seems to be focused on how it blends collaboration styles from email, IM, wiki, microblogging, etc and unifies them with a common model. That by itself is very cool. If you want a good overview from that perspective, I recommend this one at Mashable written by Ben Parr.

However, there’s more to the story. Google Wave is also a generic platform for building distributed applications with data that can be represented in XML. That’s a very broad domain, even broader than distributed collaboration.

The federation protocol reminds me of a line-oriented editor, an analogy which admittedly dates me. For any younger folks out there, this is what we had before text editors showed you the contents of the file you were editing. You had to navigate through the document by typing line numbers at the command prompt, or move forward and back through the document by a specified number of lines. Then you could insert, replace, or delete lines at the current location. If you’re on a UNIX or Linux machine, see the manual page for “ed”, a standard line-oriented text editor. One format the UNIX “patch” tool accepts is a set of ed commands. This is essentially what the server-to-server protocol sends, except the commands operate on XML documents.

When a server is sharing changes with another server, the changes are expressed as edits made to the XML document representing a “wave” (or a “wavelet”, although that terminology always makes me think of compression algorithms). You can insert characters and elements, delete elements, or split and merge elements. Once you fully grok this, the “playback” feature of the Google Wave user interface becomes a complete no-brainer.

Some of the example gadgets hint at the variety of possible applications. There’s a chess game, which I suppose could also be considered a kind of collaboration. Two people alter the state of a board according to a set of rules. Why not have a process engine gadget that alters the state of a running process (according to a set of ruls) and a different gadget for business application monitoring? Why not have an air traffic control gadget with robots that update the positions and vectors of airplanes? Ok, bad example. Maybe an air traffic control simulator game.

Some applications would be more of a challenge to build on the Google Wave model. Data models with lots of non-hierarchical relationships between objects would probably indicate a poor fit.

If you’ve missed the buzz and want to hear the news straight from Google, start from the beginning here. The original launch video from Google I/O is 80 minutes long. If you know where I can find a five minute demo to share with people, please let me know. Or if I could get sandbox access, I’d love to make one. Hint hint.

If you’re interested in an introduction to operational transformation, you might want to watch “Issues and Experiences in Designing Real-time Collaborative Editing Systems”. This one is an hour long.

Google Wave is sure to see more than its share of hype, but there’s some elegant design behind it. I’ll be watching it closely to see if it can live up to its potential.

Mar 25 2009

Bit Rot in the Cloud

From Wikipedia:

Bit rot, or bit decay, is a colloquial computing term used either to describe gradual decay of storage media or to facetiously describe the spontaneous degradation of a software program over time. The latter use of the term implies that software can literally wear out or rust like a physical tool.

One way this manifests in the cloud is with VM images that worked fine just a few months ago but have problems today. It’s not unique to the cloud, but it happens that I’ve been experiencing this with some EC2 images. Specifically, for demonstrating how to automate distributed testing with multiple browsers triggered by a continuous integration build.

A taste of some things that can go wrong:

  • REST URLs for APIs become deprecated and no longer supported
  • Services and servers move and are decommissioned
  • Strong password security policies cause expiration of passwords, prevent reuse of old passwords, and lock out users after too many retries (especially bad if it’s the admin user)
  • Xauth cookies expire and prevent access to the display

There are a couple ways to guard against this type of bit rot. One is to identify everything that depends on time or external services, then have the instance make the appropriate adjustments and diagnostic checks on startup. Another approach is to only use vanilla VM images, and do all installation and configuration through something like Puppet.

Maybe there’s also some value in using continuous integration tools to regularly exercise the VMs and their configuration, especially systems of associated nodes.

Has anybody else run into this? I’d love to hear what approaches you’ve taken to mitigate this sort of thing, and how they’ve worked for you.

Jan 31 2008

Distributed Scrum: Agile Project Management with Outsourced Development Teams

I just ran across a paper from 2006 that talks about using the Scrum methodology with distributed software development teams:

There’s also some background on the origins of Scrum in general:

The idea of building a self-empowered team in which a daily global view of the product cause the team to self-organize seemed like the right idea.

The emergent behavior of self-organizing system is fascinating to me, even apart from software development. There’s definitely a parallel to high-performing agile software development teams.

One of the interesting complexity phenomena of the first Scrum with an observed “punctuated equilibrium” effect. This occurs in biological evolution when a species in stable for long periods of time and then undergoes a sudden jump in capability.

The recommended practices for distributed teams all seem involve keeping the traditional daily 15-minute scrum meetings with the whole team. People ended up emailing their status and plans before the meeting, to mitigate language issues and keep the phone calls short. I suspect that the main benefit of actually holding the calls, instead of relying solely on emails, is to provide accountability. Otherwise it’s just too easy to publish a daily report late, or skip the reporting completely.

An Experiment

I’m the “product owner” on a team with members from two locations in the Philippines, and me in the US. We’re experimenting with an approach where the project manager acts as “scrum master” for a morning scrum, held in a chat room instead of over the phone. The log gets emailed to everyone. I review the log, respond to issues via email, and follow up via instant message for anything that requires further discussion. As a result, there’s a searchable electronic record of all those conversations, which I’m very fond of. So far it’s working out pretty well!