You've heard about them, right? They're mythical pockets of creativity, and plenty of companies have them.
If you're out of the loop, the general idea is that for some period of time, developers are unbound by regular business rules and work toward some deliverable goal, which maybe goes to production.
That sounds great, doesn't it? But let's not rush.
Ask yourself this question:
Why is hackathon work better than what happens every day?
Answer?
Your development process is broken.
Hackathons are lauded because they embody a number of qualities:
- Work that a product owner won't prioritize gets prioritized.
- Individuals can tangentially experiment to take a product in new directions.
- Developers aren't bound by normal constraints like breaking work into stories, writing tests, making things scalable, etc.
Let's address these points.
1. Work that a product owner won't prioritize gets prioritized.
Finally. We can fix the usability bug that's obvious and rampant in our product. This will FINALLY get done.
But why couldn't this work into the normal business flow? If the work of a hackathon is fundamentally more important than feature work, then feature work needs to be prioritized, and your product owner isn't very good at their job. Will features please pestering salespeople and managers? Sure, but so will the fixes you're working on if you can prove and sell your ideas. If you can't prove and sell your ideas, then perhaps your hackathon *is* less important to the business than your day to day work, and you're hurting your company by shifting to less valuable work.
If your reasoning and evidence are sound, then breaking point is the salespeople/managers you can't convince of change. If this is the case, you're probably screwed unless you're willing to slowly morph your company or organization.
2. Individuals can tangentially experiment to take a product in new directions.
If you knew your idea was sound, you would have argued for it. You're not even sure if something is possible, but you know it would have serious value if it is possible.
But why can't this exploration happen outside of a hackathon? If you can prove value, then the experiment and learning itself has value and should be prioritized along with any other work. Setup a spike, prioritize it on your backlog, and do the experiment! There's no reason to limit the number of experiments you perform to once per year, or quarter, or month, is there? That's not lean or agile or any other nice businessy word you think are good.
Experiments have value, and they have a place in the normal business process. You don't need a hackathon.
3. Developers aren't bound by normal constraints like breaking work into stories, writing tests, making things scalable, etc.
Uncle Bob Martin made the point best when he said that the process you use in crunch time, when things are bad, is the process you really believe in. If you stop continuous flow, testing, or any other part of your process to do work in less time, that's the process you think works best to deliver value per unit time.
The same principle applies for hackathons. If not writing tests or caring about maintainability are the best way to get features out, why isn't this the process you're using all the time? Just because an individual has free reign does not mean that best practices cease to exist or apply in any way.
In the best case scenario, you have to productionalize your shit after the hackathon, or worse, someone else will have to clean up after you. That's rude, unprofessional, and will absolutely make the developer who picks up the work's life a living hell for a while. And because the work was started without testing, or design, or clean code, or thought to scalability, the work will take much, much longer than if it had been developed properly up front.
So what can you do, then?
The next time a manager tries to woo you into a project for a hackathon, politely tell them that if the work is valuable, it needs to be prioritized against all other work, or priorities need to be adjusted. You should always, ALWAYS be working on the most valuable thing you can do for your team and your company, or you aren't delivering your full potential as a developer.
Build great software, and just as importantly, build great companies.
