Disclaimer: I never took part in a hackathon for the reasons I explain here. So all views are deduced from observing those events and their outcome.
Under which conditions would you say a software project goes bad? Let me gather some I really dislike:
- We’re in a hurry i.e. we are short in time
- We are actually so short in time that we can’t complete each and every task
- We don’t have a good set of requirements
- Outputting something counts more than doing it right (“quick and dirty is better than nothing”)
- We have so much work to do that we ignore our health condition (at least for some “sprint time”)
Nearly every condition I mentioned above can be found in a hackathon. Because it is a challenge. Work fast, achieve most. And who attends a hackathon? Young people. Developers starting their career in tech.
What do they learn in a hackathon? Work fast, complete as many tasks as possible. Doing it quick and dirty is perfectly OK. If you don’t have a specification for a task, guess whatever you think will work and implement that. It’s OK to sit 3 days (and I mean DAYS including the nights) in a room and hack right away, ignoring how your body feels.
NO. Just fucking no.
I don’t want people to learn that quick and dirty is the standard way to do things! I don’t want them to learn that scarcity in manpower, time and quality is perfectly acceptable!
To be clear: in every project I worked there are phases when time is short and we needed to do something quick and dirty. But I always try to implement things the best way I can.
“We need people who can fix things quickly!”
Training people to quick and dirty as a standard might be exactly what the organizers aim at. I prefer my coworkers to learn to do things first right and then fast. And to find shortcuts where needed.