On Hackathons

Going back to the hotel, I realized that during the hackathon, the tight schedule had forced us to do pretty much everything that we all know you should not do. And that we had just experienced a “real” project situation: a tight deadline, not enough communication “because we have no time”, rushed technical decisions like just using HTTP “because we have no time”, doing things quick and dirty “because we have no time”. Does that sound familiar to anybody? Exactly: most teams that I have met (and I have met many of them) experience just this on a day to day basis. And it is wrong.

Dear organizers of that hackathon: I thank you very much for making this event possible and all the effort you put into it. It has been great fun, and I have learned so very, very much. It has been a priceless experience. As a consequence, I will never ever take part in a hackathon, because it forces us to do pretty much everything the wrong way. When developing software, the goal is not to write a lot of code as quickly as possible. We need to communicate. We have to agree on how we do things. We have to get everybody on the same page. We have to make conscious decisions. We need time to understand the requirements, and we need a feedback loop to clarify them, especially when we think they are flawed. We can never make compromises when it comes to security. Who cares whether our web server is secure, we just had 15 minutes to set it up, and thanks to cloud computing, who would ever assume that it might take longer to actually think about how the live environment should be configured.