Thursday, January 24, 2013

'Let me Hackathon that thing'

'Every good piece of software starts by scratching a developer's personal itch', says Eric Raymond, author of the fabulous book on Open Source software, The Cathedral and the Bazaar. Hackathons evolved to harness that personal passion of software developers to create interesting code that solves problems - or sometimes, just create elegant, interesting code simply to see what happens. Organisers provide a context - for example software platforms such as Ushahidi that constantly need to to be improved or movements and campaigns such as development data or aid transparency which need lots of programmes to import and aggregate data or present the data in a form usable by others and the public - and a space, with coffee, cakes and chocolate. Developers who enjoy working individually or in teams and are moved by the spirit of the organisers come together and have fun.

The Research to Impact Hackathon is different in significant ways to a standard hackathon. Firstly, there is often criticism that these events produce a lot of interesting but unfinished code, which is either taken over by the sponsor and developed internally or simply abandoned, with the developers un-engaged in the follow up. The sponsors of this event, IDS/ELDIS and CABI/R4D see this event as Phase One in a longer term process. They are providing small prizes for the best products but committing larger sums to supporting the development of particularly promising ideas and prototypes that have the potential to increase the use of research data.

Secondly, we wanted to provide focus to the developers based on an informed understanding of specific challenges faced on the ground, in East Africa, by those working in agriculture and nutrition, challenges which constrain the use of development data and opportunities it offers to enrich the development process. However, we had to steer carefully between being too directive of the developers - which could reduce creative and risk appearing to be asking for some free labour to help large organisations solve their problems - and not providing a clear enough set of scenarios.

So we were a bit anxious about how Day Two of the Hackathon would develop, especially since we were joined by some new developers who hadn't had the introduction to the personas, challenges and triggers which emerged from Day One of the Hackathon nor been part of the Ideation session. We should have known better: we are in the iHub, in Nairobi, Kenya, at the centre of a vibrant developer community, supported by the ideas and contacts of iHub Research. Many of the participants had been trained in mobile application development at the mLab - yet another source of energy within the iHub ecosystem (and the iHub is not even three years old!). And all the developers were in some way or another connected or developing software solutions to the needs of those in the agriculture value chain.

We introduced the data available from ELDIS, R4D and other relevant open data sources, including the World Bank's data site and the rapidly growing Kenyan Government OpenData portal; the ways to access the data through the ELDIS open API and the tools which Tim Davies is developing to access the data, including in Linked Data formats. Finally we introduced the personas from Day One, together with the ideas which had been rated as having the highest potential impact and most viable as the basis for developing a Proof of Concept in only two days (and nights!).

Chaos of the most productive kind ensued. People discussed ideas; formed, and reformed, teams; ate sausages; asked for more information about the personas; drank coffee; got support in exploring the data and learning to use the access tools available; fed-back ideas for discussion; storyboarded and planned; ate cake; began to hack. By the end of the day four groupings of ideas and people had emerged, all interesting and within the frameworks we had established, and some with the beginnings of demonstration code - either created or imported. Then we went for beer.

Day Three is a hack-day: teams will continue working on their ideas, preparing for a presentation on the morning of the fourth day, in some kind of Dragon's Den format. While the progress has been remarkable for two days, the acid test is, of course, what the teams can present on Day Four. Given their commitment to the longer term, the organisers are looking as much for coherent plans and realistic assumptions as finished code - but watch this space.