A hackathon is a wonderful thing for any project, be it a community driven project like Taarifa or something that ships ‘professionally’. The idea behind it is simple, get hackers in a room, ply them with food, drink and ideas and 48 hours later reap the rewards of their work. The problem is it’s not often where a project continues after the hackathon. Taarifa in many ways broke that trend, by its developers continuously communicating, adding code, patching bugs and the such like.
We were joined by new developers, some who were corralled into the project by the original developers, other brought in by friends of friends. Taarifa as a project is getting bigger! Assembling for the first hackathon since the first we sought to address problems caused by new bugs and already existing ones. One of the mistakes of many coding projects (especially ‘hacks’) is that the developer is in the mindset of putting in new functionality before fixing known bugs. Bugs are always going to be found, but you’ll be building upon shifting sands if you don’t fix what you already know. Simply because when you go back and fix old problems, they’ll often break newer code down the line.
Part of this is about making it easier to develop and the code base ‘better’. At the original hackathon we took the Ushahidi code base because of the functionality which was included out of the box. We hacked it to make something that looked like it was working. However we now realise that this wasn’t the best strategy for sustainability. Though what we had done worked, it was not ready to be deployed and put into release. The opinion of the developers on Ushahidi’s code base, using the Kohana framework wasn’t good. Finding something as simple as a HTML header took two developers a few hours to resolve with more complicated issues requiring a ‘strong investigative ability…’
While this bellies the importance of documentation, sometimes this isn’t enough. Making code simpler and easier to use isn’t just good for new people joining a project, it’s good for your existing development team as well. In the context of a hackathon this is really important because time is also a consideration. In Taarifa practically all the ‘significant’ code base has been written in these two day sprints, and we’ve only had two events. To engage more developers and contributors in the project we now need to work on communications and other non-code matters. Now we’ve a bigger and more engaged community than before. We have contributors from many countries around the world, an active mailing list, github repository and live demo and development sites. To coin a ’90s phrase: the future’s bright. The future’s Taarifa.
Written and submitted from the Isle of Dogs, London, UK (51.487291,-0.0183036)