In his post over on thePHP.cc site Stefan Priebsch talks about hackathons and why they should possibly be considered harmful. Here he's talking about the ones where a project is given at the start and a product is expected at the end, not just general time for developers to hack together on their own projects.

Last month, at a conference in Bulgaria, I participated in a hackathon for the very first time. The task was to build a small REST API for the tracking of shipping containers and a frontend to visualize a container's GPS position. I would like to share some of my thoughts and experiences (and this is neither going to be about the code we wrote, nor about the fact that we won).

He talks about the team that he was a part of and the different pieces they each contributed. He notes one unfortunate thing though: due to time constraints (3 hours), ramp up time and planning of the application, corners had to be cut to make the deadline.

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.

He suggests that hackathons, in this particular format, should be considered harmful as they reinforce bad decision making and poor development practices. He offers some suggestions that could help to make future events better and an offer to provide guidance for those wanting to make a better event.