Most hackathons are commercial endeavors. Organizers pretend it's for fun and honor, but that's not the real reason. To a certain extent that's fine, it's a break from everyday routine, having some fun, show off your skills as a developer.
Except for the strings attached.
More often than not the code you hacked together in a hackathon, is used in production code, for you to maintain and develop.
The consequences are dire: you yourself have laid the foundations for a "ball of mud" architecture, which will result in chaos, bugs and spaghetti code. Eventually, managers will blame you for the chaos they asked for.
How to keep hackathons all fun and games, impress everyone without risking to burden yourself maintaining a product built on a hack? Here's a plan.
How a hackathon puts you on the spot
You want to be cooperative and partake. If you don't, your super-ambitious co-worker will, and take all the credit. You want to look good, you want to make your team look good.
It's a chance to show managers that you are more than the modest lab coat you are taken for; perhaps a career jump. If there's a 8-feet cardboard check with prize money involved, even more so. You want to put your best foot forward. It's an honor you can't refuse.
It's a bittersweet victory if the hackathon is successful, and what you feared does happen: the brass is so impressed, they want to use your hacks as a product. The harder you hack, the more you impress people, the bigger the chance that this happens.
Then it's too late, that project is airborne and hacky code ends up in production. The only defense you have left is downplay: your code is just a quick hack and no basis for production code. But you'd make yourself look like a bad coder.
You need to take preventive measures, and they should start when the hackathon is announced.
Expectations of hackathons
Commerce sees a hackathon as a form of event marketing. An innocent and low-cost way to get developers involved.
Developer reasons to start a hackathon
- Discover how something works
- Discover if something works
- Find creative solutions for unsolved problems
- Create positive competition
- Introduce a language or technology in a playful way
- Team spirit
- Learn
- Fun
These are all good reasons. A self-organized hackathon is powerful, good and ethical.
Commercial reasons to start a hackathon
- Pitch to select a vendor
- Cheap start of a new project
- Market a product or API to developers
- Manager impressing others with the skills of his/her team
- Get software for free
- Recruitment
Let's not sugarcoat it: you are being used and fighting for someone else's goals.
Hackathons turn appreciation into a scarcity to let developers compete over. If you don't play, someone else wins. That is unethical if the agenda is to put not-production-worthy code in production and let its creator sort out the mess.
Manager's perception of hackathon results
Managers assume that if it works, it's almost finished. When you put an executive's name in a widget, they assume you just added configurability. A hackathon is happy flow overfocus in overdrive.
To make matters worse, hacky code often is lighting fast. This impresses managers even more. To you it's obvious why it's so fast. There is no error checking, nothing is dynamic or configurable, there is only one user, and the data set is tiny.
If you try to warn that this is just a hack, managers think you're being too modest.
Why managers don't mind using hackathon code
There are two types of managers when it comes to hackathons:
Believers
They are fueled by the romanticized image of hackers in hoodies in action movies and espionage thrillers. Believers see hacking as a way of pressurizing developers, which brings out some kind of secret superpower. Suddenly, everything that takes months with people acting all difficult, is possible in a matter of hours or days.
Risk takers
They know that hacked code is fragile and immature, but see that hacking generates a focus to the essence of the problem and solve it fast, and a boost of trust in developers' own capabilities. Risk takers are confident that bugs and incompleteness can be tidied up along the way. It's ugly but fast. Putting code into production early keeps developers on their toes, focused on a goal- and priority-oriented attitude.
The difference between hackathons and reality
Both management beliefs have some basis in reality, but unfortunately, not enough. Hacks are wiggly. The more you build on top of hacks, the wigglier it gets. Skipping a solid foundation means paying a tenfold maintenance cost, low evolvability and bugs.
The only way to go fast, is to go well
-George C. Martin, "Clean Architecture"
When a hackathon was a success, managers are on cloud nine of momentum. The last thing they want to hear now is: "Yeah but it is faster if we just rebuild this from the ground up". It is true, but managers fear that it's going to take months, the very thing the hackathon was supposed to prevent. Managers know by experience that this happens and they are right.
Strategy to prevent hackathons in production code
You need to create safeguards, and you need to do it before the hackathon takes place. This strategy has three steps:
- Manage realistic expectations before the hackathon
- Control the perception during the hackathon
- Keep the initiative after the hackathon
This is no guaranteed formula, there always is a chance that your manager just overrules you.
Step 1: Manage realistic expectations before the hackathon
The very announcement of an upcoming hackathon should make you cautious.
You should talk to managers and investigate what their expectations are. It's good to explain early on, before the hackathon, that you will be making throwaway code.
The knowledge gained from a hackathon is priceless, the code itself is worthless.
Whoever disagrees, says nothing, or says "don't worry, it's OK if it's quick and dirty", reveals their true intent right there.
Step 2: Control the perception during the hackathon
If the hackathon went well, your chance to rebuild hacky code from a solid basis might be gone before you know it. The very next day, the team may be planned to turn the hack into a demo fast, and this demo also is the product. You need to take precautions during the hackathon.
What happens with a hackathon's results depends on perception; since you write the code, you can influence how it's perceived. It should be crystal clear to everyone that this code must be rebuilt and cannot go into production, but without making yourself look like a bad programmer.
How? Add something that blocks use, in a nice way, but unavoidable. For example, count the times the key feature of your hack is used during a run. After the third successful time, pop up a modal dialog saying "Thank you for watching this demonstration. Quit?"
Everyone who watched the demo has a different mindset now, and understands the narrative: that this was just a demonstration, and the demo will now quit. It is clear this cannot go in production yet.
Be sure to add these safeguards very early during the hackathon and comment it out. So you don't have to think of it while hacking. Uncomment it when it's time to demo your result. Later you will be asked to remove it, but they depend on you to do that. This is your chance to retake the initiative and present your plan.
Step 3: Keep the initiative after the hackathon
To managers, the problem with developers protesting against using hacky code as a basis for a new project, it's all just objections and complaints with no plan what to do instead.
So make a plan. What are the features for a good product based on this hackathon? Describe an outline of that product. Make a comparative estimate of the deliverables. Estimate the right column first. How much work are these features, if you'd start greenfield, with all the learnings from the hackathon in your mind?
Once you have figures, it's easy to estimate what it would take to build the same thing while keeping your hackathon code intact. Usually it's a lot more work per feature; my personal experience is 2 to 5 times more. Put it in the left column.
Activity Days from hackathon Days greenfield
----------------------- ----------------------- ---------------
Clean up the hackathon result 1 -
Rebuild hackathon idea from scratch - 5
Coveted feature A 3 1.5
Coveted feature B 2 1
Coveted feature C 5 2
Coveted feature D 1 0.5
Coveted feature E 5 2
Testing and debugging 7 2
---- + ---- +
Project total 24 14
Both estimates must be realistic and withstand challenging. If it's many features, summarize them until the estimate fits on half a page. It's supposed to convince in a single look.
The effect on decision makers
It is much easier for decision makers if the consequences of right and wrong scenarios are spelled out right in front of them. If it's in the form of an actionable plan, even better.
Observe how managers see these figures and whether they attempt to make the problem smaller by juggling around with your numbers. It may feel like trying to shorten the journey by removing parts of the road. But it's a good sign. It's part resistance crumbling, part testing to see if your estimate is sound and solid.
Good leaders will be taken aback positively by a sudden solution-oriented initiative. Your figures will now become the first goalposts and get a life of their own, so estimate carefully.
Mind the pitfalls
Do not provide a bandwidth. Managers will only look at the low number, and if the spread is too big, they think your estimate is too inaccurate to be relevant.
The same effect can happen with maintenance cost. Maintenance of a product based on hacks is hugely expensive and it rapidly gets worse over time. But how bad, is hard to quantify; it could be 4, 10 or even 200 times more expensive than a well-architected product.
Here too, figures with wide margins don't "feel" credible. Nonetheless it's good to add a paragraph on maintenance cost being way higher, as an additional warning.
You should be aware that the window of opportunity to come with a plan is short if the hackathon was very successful. It might be a week, it might be a day. It's smart to think about your plan before the hackathon, so that you can draft it quickly.
What does not work
I have witnessed many developers attempting to stop hacky demo code from going into production. Here's what doesn't work.
Putting the word DEMO on top
Ample use of the word "DEMO" in very visible places puts non-technical people on the wrong foot: they assume you mean this is ready to demo to customers. It's OK to say "DEMO", but it's not going to protect you.
Make it ugly
To underpin it's just an experiment, developers sometimes purposefully make the UI or layout so ugly that this obviously could never go in production. Unfortunately, what looks unacceptable to you, might be "good enough for now" to someone else. Or worse, they even like your "design"!
It is tempting to have fun and go overboard: use edgy political memes and forklift fail GIFs for pictures, and put jokes and funny punchlines in headings and names. After all, it's a hackathon, right? True, but it's not going to protect you.
Why it doesn't work
Managers and commercial people, in their hot pursuit of success, totally overlook your jokes and memes. Their minds are not on the demo, their minds are on the business chances opening up if they convince an important person. Often, no one thinks about tidying leftover content from hackathons to begin with. It just stays right where it is.
I have witnessed numerous proud and official demonstrations of software, watching test content of oops-, facepalm- or even NSFW-levels of embarrassment, triggering the customer to make remarks and the prospect's attention to the demo is gone.
What is a healthy hackathon culture?
Hackathons should be organized for and by developers.
If the management wants developers to partake in a commercial hackathon anyway, they should not shy away from telling the commercial reasons, and formally confirm that all code is throwaway with no strings attached, so developers feel safe to play and do really gory things with code without fearing that it will be used in production.
Managers should be aware that developers get very little or no reward for their technical achievements, and that it's just wrong to leverage this scarcity through hackathons. Appreciation isn't pie.
Instead, managers should take active effort in being interested in technical things developers do, and show true appreciation for their skill and talent. Who can't bring that up, should not manage developers. Any appreciated person will show significantly more productivity, performance and initiative. Developers are no exception.
Conclusion
If a commercial hackathon is announced, count on what's coming next: your code can and will be used. Deploy the strategy. Manage expectations. Add the "thank you for watching" safeguard early on. Make a plan, what this hack would look like as a full product. So that when you hear someone saying "Wow, what a great start for a new product" during the demo, you already are three steps ahead.