It just occurred to me that Hackathons which stress on the caffeine-induced sleepless continuous-production aspect of programming are the opposite of what Rich Hickey termed "Hammock driven development" : http://data-sorcery.org/2010/12/29/hammock-driven-dev/
I guess the "furious activity IS productivity" approach of such hackathons is appropriate if you're building the next great website where the assembly of components is the challenge but they are probably not great for solving open-ended problems such as designing an algorithm or figuring out how to solve a puzzle (a business puzzle, a programming puzzle, a life puzzle).
The description of "Hammock-driven" development is very similar to how one has to function in academia, where the problems are hard and a lot of time thinking is necessary.
I also like to operate this way - the solutions created in such moments of brilliance just cannot be reproduced while in constant states of stress.
I guess the "furious activity IS productivity" approach of such hackathons is appropriate if you're building the next great website where the assembly of components is the challenge but they are probably not great for solving open-ended problems such as designing an algorithm or figuring out how to solve a puzzle (a business puzzle, a programming puzzle, a life puzzle).