The importance of hackathons

Hackathons have become common practice of many companies.
15 years ago while working for verint, we were three programmers from different disciplines that convinced our managers to let us take 3 days each quater to tackle a bug/ system problem/ feature which needed a boost. We would then dedicate these days (And nights) to come up with a working solution or prototype, which sometimes changed the way the company works, solved a major problem for one of our customers, or just accelerated a process (Like performance analysis or enhancements) which could not be done in the normal lifecycle.

Such practices are even more important in large companies. Developers in companies which have a slow, long waterfall type (Even if daily work is agile) processes tend to become more 'typewriters' than 'code warriors' (Or ninjas :)).

A hackathon brings back the joy of coding and creation to such people.

A successful hackathon not only does that, but also shows the rest of the organization what you can accomplish in short bursts and by cutting red tape. Projects that were estimated as months were finished in days. This shakes up your organization, and sometimes makes a good reality check for the way organizations work.

I'd like to finish with some basic recommendations for hackathons:
- Set the goal before beginning. Make sure it is presentable later. (Working demo would be best, even if all you're doing is performance enhancements)
- Remove all of the mondain tasks from the team - This is crucial.
- No processes. If someone is managing the hackathon, the only meetings allowed are brainstorming.
- If applicable, add a product/ UX member to the team. For example, a GUI person can provide you with insights which would give your result much more impact.
- Make the team diverse as possible, but make sure the team is composed of people who can work together. This is not about bonding.
- Start coding as fast as you can.
- Make sure your result is shown to as many people as you can.
- Don't promise anything in advance, but try to reward the team after a successful demo.

Don't bury your best coders in documentation and meetings. Good coders love to code. Let them.