I participated in a range of hackathons over the last years. Just this weekend, I took part in the latest energyhack which made me realise how much my opinion of hackathons has changed. I now think that hackathons, as I have experienced them, set the wrong expectation for how software development works and miss the most fundamental point of software development: We write software to provide tools to users. In order to know what tools to build, we first need to talk to them.
In a traditional hackathon format (especially one that is somehow based on new data being provided), the setup usually follows an established pattern. People come together and get to know each other, the organisers present their problem description / challenge and demonstrate the data or API that has been newly made available for this hackathon. The participants are then expected to think about ways to “solve this problem”, form groups and spend the next hours working on their prototypes. They go away into their little chambers, write lots of code and eventually return with a presentation which the original organisers then judge and possibly pick a “winner”.
Note the absence of the organiser in this setup for the complete time of the development effort. This is just not, how software development should work. It is, in its essence everything that is wrong with software development and I was hoping that we as the software development community had slowly found our way out of it throughout the last years. In the traditional format, developers - mostly privileged dudes with their tech goggles on, start working on software that they think will help with the problem. Could it actually help though? In order to figure this out, they should talk to the domain experts - the very organisers of the hackathon. After all, those people though that they had a challenge important enough to invite people to work on it. They probably know a thing or two about the domain that is being worked on.
In the professional context, agile methodologies have now found their way to most teams because they deliver better results. I think that a big part of the reason why agile works is not because of daily standups but because of the idea that every sprint, developers, designers and product people come together to discuss new features. In this process, the product owners can present the issues that they would like to see solved and propose solutions. The tech people can then make a call on the feasibility from a design and tech perspective. They can propose alternative implementations for which the product people (the domain experts) can then check if they still help with the original task. These dialogues make sure that the software that is being written actually helps.
It has been noted in other articles already (e.g. in this German article by stk) that we need a more long term setup instead of the expectation that an organisation can simply invite a couple of tech people and then walk away with a perfect solution to their problem.
So, imagine you are a German governmental body and you would like to run a hackathon. What should you do? First of all, you should make sure that you are set up for long term collaboration with the community.1 You can then invite people to your hackathon and bring your smartest people yourself. You want to bring the people that have worked in the field for a while and know all of the potential problems and pitfalls 2. You might even want to bring some lawyers to make sure that they don’t ruin the fun at the very end, telling you that your idea is not possible given the governing laws. Is the goal of your hackathon to help a third party? If you want to for example “solve homelessness”, you might want to invite a couple of homeless people to hear what they think about the ideas that you are proposing for them. Once you got all of these people together, you can start forming groups where all parties are represented. This allows you to “build with, not for”. The newly formed groups can then take the time of the hackathon to talk about potential approaches and to discuss upsides and downsides. They might even be able to start developing some clickdummies already or to check if something is technically possible, but they should not be expected to go out of the event with something that works. This will have to come at a later point through long term collaboration.
All of this probably does not sound as exciting as “24 hour of intense coding” but I believe that it is a much more sustainable solution for all parties and might actually help in delivering something that is of value in the end. Lets not forget: We can never develop “solutions”, if we can do anything, we can build tools. And in order to build the right tools, we need to do one thing first: talk.
1. From working in this environment for a while now, I have learned that this is not trivial: If the government is available for collaboration at all, they are available during the day job hours of the community. When the community meets, they meet outside of working hours of the government. This makes it difficult enough already to meet at all.↩
2. At the energyhack I have for example talked to the Berlin fire brigade which has lots of interesting data about the calls that they get. They do not want to publish this data as they fear that one could use the addresses to draw conclusions on the people that live there. This made immediate sense to me. When I proposed that they could publish data on an aggregate - e.g. neighborhood - level, they told me that they had also thought about this already but that they feared that insurance companies would use this to increase rates for high risk neighborhoods. These are the kinds of disussions that we should be having. ↩