Some reasons why you shouldn't organize a FedEx day (ie, a 24-hour hackathon. This is different from a company-sanctioned hackathon that occurs during business hours. I think those are great.)
1. It can bad for your employees' health.
2. It shows a lack of respect for employees' personal lives.
3. It discriminates against workers with families.
4. You don't compensate workers for it
5. You can't write good software when you are tired.
I'm glad this article implies that employees need not stay up all night, as Facebook Hackathons seem to promote. Such events are heavily biased toward the participation of the young and childless who have few mandatory scheduled responsibilities outside the workplace such as childcare. Of course, participation ostensibly is voluntary, but it's clear that there are career benefits such as making oneself known to upper management by presenting one's hack. Companies who schedule these sorts of events likely send a message unknowingly -- If you can't pull and all-nighter, you ought to consider working somewhere else.
In total contrast, I once worked for a staid, rural insurance company where the majority of employees were middle-aged with children. "Flexible" hours meant that one could arrive at work anytime between 6AM and 9AM. Clearly, the flexibility was extended to those who wanted to arrive early so that they could be home by the time their children were getting off the school bus. Twenty-somethings who wanted to venture into the city to see a show (easily an hour drive) still ostensibly had to arrive at work just a few hours after getting home. These family-friendly policies sent a distinct message to the young/childless -- the company regards your happiness as secondary to that of those with children.
Edit: I regard such policy biases as companies' choices to make, but I doubt that many consider sufficiently the messages these events/policies/etc send to particular employee segments.
It's a startup, and I've read 10+ articles on HN saying "< 40 hour work week is most efficient for technical work".
While I agree, focusing on getting something shipped every 2 days isn't a huge pace. It means you iterate tightly and goals are understood to be scoped to only 2 days of work.
If something slips the 2-day goal, it's debt, and it's expected to be nailed first-thing in the next sprint. It's a flexible system.
For bigger projects, you _have_ to be able to split them up. I honestly can't think of a single project where you couldn't break it down into constituent parts in which you could iterate through several sprints to finish it.
If you're doing research-based work, I'll admit this probably isn't the best approach. However, from a business and personal productivity perspective, it's working very well.
I understand the cultural allure of a single event -- pizza, beer afterward, etc. If a company wants to allow all employees to participate, why not have a demo day every couple of months where teams could present stuff they worked on during that period. People could self-organize partially by their own time availability. Enforcing the time-boxing rules would be hard, but I don't think this is an integral aspect of what makes hackathons a cultural success.
At one company where I worked, the advertised benefit to employees was, "You get to choose what you build for the company! You can INNOVATE!" Not these words, but this was the message. If you want to take initiative to improve things around here, you have to do so on your own time.
Interestingly, I ended-up spending much of the hackathon day an evening fixing a production problem which was of obvious urgency. Some mild shaming from management ensued when I had nothing to present -- a clear message.
1. It can bad for your employees' health.
2. It shows a lack of respect for employees' personal lives.
3. It discriminates against workers with families.
4. You don't compensate workers for it
5. You can't write good software when you are tired.