A suggestion for increased SME involvement at hackathons

During the weekend of September 21-23, a group of hackers and disaster management specialists met at Aston University in Birmingham, England to work on software to support the needs of civil defense managers before, during and after a disaster (see http://h4d2.eu). The weekend was successful in moving several existing projects forward in development as well as kickstarting one new program. Throughout the event, I had the opportunity to sit down with a few participants to discuss their experience in disaster management and what they would like to see us work on in future Hackathons for Disaster. I learned a lot in during those conversations, and plan to share the learning in a series of posts here on GWOB.org.

Hackathons like H4D2 bring a group of subject matter experts (SMEs) together with programmers and other technology experts (hackers) to solve problems in a specific sphere. In April 2012 there was the International Space Apps Challege that brought space agencies like NASA and their data together with hardware, software and data hackers to build new things with existing knowledge. Random Hacks of Kindness brings various humanitarian needs to groups of hackers every six months. A whole host of other one-off and repeating hackathons try to get the most out of putting SMEs and hackers in a room for a weekend to see what happens. With the flurry of so many events, are we taking full advantage of the knowledge of the SMEs at these events?

It seems, from talking to various experts who have lent their time at these events, that a lot of the SMEs feel at loose ends after the first hour or two of a hackathon. They have knowledge to share, and problems to define, but after the lightning talks, the hackers tend to get busy doing magical code things, leaving the SMEs out until the unveiling at the end. Often SMEs kick about for a few hours until they feel like they are just taking up space, and then they go home feeling that they aren’t needed. We can and should find better ways to integrate our subject matter experts into the process.

Eduardo Montero told me about a project he worked on in Spain where the emergency management experts worked together with programmers to solve some software needs. Groups of police, fire and EMTs each sat with a programmer who was working on a piece of the software. They had a large screen in front of them so that everyone could see what the programmer was doing. They could look at a thing, say “this button should wiggle with an alert” or “can you make that bigger?” and it would happen right there. As a result, the emergency experts got a better idea of the work involved in building their software and the program they needed was built to their specifications in real time.

Something like that could change the way that SMEs function in hackathons. If we encourage a Team up/Pair up methodology, we might be able to build better tools for everyone. Here’s how it might work:

Team up
After the initial lightning talks, groups split off like they normally do. Each group should have at least one subject matter expert who will work with that group. Instead of jumping into code, the group would have up to a 60 minute planning session that would include much more detailed information from the SME about existing tools and problems related to the challenge that group has taken. As the hackers think up the architecture of their solutions, they would describe those solutions to the SMEs to get feedback before they even start. Having decided on a plan of action, the group would split off to build the pieces.

Pair up
Ideally, at this point, there should be one SME to every hacker. They can sit together, work through the problems and see if what’s being built actually does what the people in the field need.

More often, since the number of hackers tends to far outstrip SMEs at these events, a single SME would go from hacker to hacker in intervals, ask questions about what they’ve done so far, and give feedback along the way. By sitting with each hacker in the group for 20 minute intervals, the SME would get a much better idea of what was happening with the project and be able to steer it when needed.

Plan a bit, code a bit, share a bit.
Every 2 hours, the group would meet together again for a 15 minute breakdown of progress, challenges, and changes. Certain parts of the original plan need to be adjusted to fit what has been learned while building. Hackers may also use this time to reach out to each other for additional help with obstacles without feeling like they are interrupting each other.

Some hackers may feel like this is too much talk and too little code. Experience from professional environments says quite the opposite, though. It pays to plan more, and to take breaks to iteratively assess the progress along the way. This is true whether you have one year to work on a project or just one weekend.