I participated in a few coding competitions in high school, where we got together for a day with a team and tried to build software to solve a problem. They were challenging and exciting, but exhausting. Not something I'd want to do often.

A number of corporations have tried something similar with internal hackathons as a way to find internal innovation and inspire employees. Getting a day, or a few days, to build some software that might change an organization can be exciting, but the events are not without some drawbacks.

I've liked the idea of us doing this at Redgate, with our Down Tools Week, but the CIO of TD Ameritrade finds hackathons useless. The reasons he gives makes sense, and they are problems I've seen in various organizations when employees want to build something new, without necessarily understanding the problem or having the resources to complete their work. I mostly agree that unbounded hackathons are problematic, and having some evaluation of ideas is important.

It's hard to be innovative constantly in an organization when you have pressures and deadlines to complete work. At the same time, it can be easy for an entire development department to stagnate because writing software to close out tickets someone else has submitted. That's boring, uninteresting work in many cases, and it can reduce incentives to build great software. The ideas in the TD Ameritrade piece are good, allowing a team to be sure developers aren't solving a problem that's been evaluated, or choosing a solution that is impractical. I like the idea of funding ideas and increasing that over time if ideas show potential.

Ultimately there are often lots of ideas on how to solve a problem with software, but we rarely work in a vacuum. Our solutions have to fit within an existing structure and have a ROI that makes sense to the organization. Whether we sell software or support some other business, we are trying to achieve those goals, not just solve the problem in the most satisfying manner. Too often I think software developers sometimes forget there are goals other than just producing code that completes a task. Usually those goals are furthering the organization in some way beyond the software.