Wie man einen Hackathon gewinnt

7 einfache Schritte zum Erfolg bei einem Hackathon an der Cloud Foundry Summit

An der letzten Cloud Foundry Summit in Philadelphia gewannen mein Freund Benjamin Gandon (von Gstask.io) und ich den zweimal pro Jahr stattfindenden Hackathon zum zweiten Mal in Folge. Im Nachhinein wurden wir zwei gefragt, ob wir unser Wissen wie man den Wettbewerb gewinnt teilen könnten. Die Fragen kamen auf, da dies mein dritter Gewinn bei vier Teilnahmen war.

Für alle von euch, die nicht wissen was der Hackathon ist: An jeder der letzten fünf Cloud Foundry Summits (in Nord Amerika und Europa) organisierte die Cloud Foundry Foundation zusammen mit IBM einen Wettbewerb um das Cloud Foundry Ökosystem in irgendeiner Form zu erweitern. The Wettbewerber müssen dazu Gruppen von bis zu vier Personen bilden und ihre Software in etwas mehr als einen Tag entwickeln. Anschließend gilt es ihre Arbeit vor einer Jury von Cloud Foundry Silberrücken wie Chip Childer oder Michael Maximilien zu präsentieren.

Um euch jetzt auch fit für den Wettbewerb zu machen, habe ich Euch meine Erfahrungen zusammengestellt:

Am Anfang des Wettbewerbs müsst ihr eine Idee haben, was ihr während des Wettberwerbs entwickeln wollt. Dabei tendieren die Teilnehmer gerne dazu, eine Lösung für ein Problem zu wählen, dass sie in ihrem kleinen Teil des Cloud Foundry Ökosystems besonders stört. Das ist immer cooler Kram und hilft einer Menge Leute in genau dieser Nische. Aber wenn ihr einen Hackathon gewinnen wollt, dann muss eure Idee besser sein als die eurer Mitbewerber. Also zielt auf eine Idee mit großem Einfluss auf Cloud Foundry. Wenn man sich die Gewinner der letzten Wettbewerbe ansieht, dann wahr keine kleingeistige Idee dabei:

• Fusion von Function-as-a-Service (aka serverless) mit Cloud Foundry – wie man heutzutage cf map-route macht um eine Applikation auf eine Route horchen zu lassen, soll man auch Events an eine Funktion heften können, die vorher auf Cloud Foundry gepusht wurden
• Software-as-a-Service-Broker – Entwicklung eines Service Brokers, der in der Lage ist automatisiert Applikationen, die vorher auf Cloud Foundry gepusht wurden, im Marktplatz buchbar zu machen
• Fusion von Blockchain und Cloud Foundry – Entwicklung eines Hyperledger Service Brokers mit dem man Cloud Foundry Applikationen die Blockchain nutzbar zu machen
• Ein Package Manager für BOSH – Entwicklung eines zentralen Package Management Servers und einer CLI zum Verwalten von Packages für BOSH releases und um diese leicht zwischen Projekten zu teilen
• Careless Delivery (aka Project 42)  – Das Erweitern der cf push Erfahrung auf die Erzeugung von CI/CD Workflows

Die Zeit bis zum Ende des Wettbewerbs ist knapp bemessen (etwas mehr als ein Tag). Also fokussiert euch auf sehr kleine MVPs (Minimum Valuable Product) und erweitert diese wiederum in weitere kleine Iterationen. Ich kann gar nicht genug betonen, wie wenig Zeit ihr habt. Solltet ihr irgendwelche unerwarteten Probleme oder Schwierigkeiten haben und mehr Zeit für die Lösung eines Problems benötigen, dann ist es im Prinzip schon vorbei.

Der Schlüssel zum Erfolg ist, immer schnell auf ein vorheriges, möglichst zeitnahes MVP zurückgreifen zu können. Besonders für den Fall, dass ihr eure Lösung präsentieren müsst und ihr nicht mit der letzten Iteration fertig geworden seit. Ich empfehle euch mindestens alle 2 Stunden ein neues MVP fertig zu stellen. Letztendlich heißt das, dass die Unterschiede zwischen den Iterationen extrem klein sein müssen.

Enormer Zeitdruck und den Wille eine zukunftsweisende, große Idee zu entwickeln, diese Kombination ist von Anfang an zum Scheitern verurteilt. Entwickelt man seine Idee in der knappen Zeit trotzdem komplett fertig, ist sie in der Regel weder zukunftsweisend noch groß.  Relevant wird eure Arbeit erst dann, wenn sie eine Vision enthält und ihr diese vorantreibt. Diese Vision hinter eurem Projekt, das ist es was ihr am Ende des Wettbewerbs verkaufen müsst. Die Jury weiß, dass ihr die fertige Entwicklung nicht vollständig erreichen könnt. Was sie sehen wollen ist, dass ihr eine Vorstellung der weiteren Roadmap für die Zeit nach dem Wettbewerb habt. Dass heißt nicht, dass ihr nichts entwickeln müsst. Aber ihr präsentiert eben ein Zukunftsszenario, nicht das tatsächliche Endergebnis. Der Hackathon soll die Cloud Foundry Community inspirieren, zusammen an neuen Projekten und Ideen zu arbeiten und dabei neue Impulse geben und neue Maßstäbe setzen. Also zielt auf etwas, dass nach dem Hackathon ein neues Incubatorprojekt werden kann. Außerdem ist eure Präsentationszeit knapp (5 bis 10 Minuten zzgl. Fragerunde und inkl. Demo). Vertraut eurem Know-How und legt den Fokus auf die Vision.

Während des Hackathons itereriert ihr extrem stark und schnell. D.h. ihr produziert ungefähr alle 2 Stunden ein MVP. Am Ende benötigt ihr etwas Funktionierendes für die Demo während der Präsentation. Bis zur finalen Version eures Codes werdet ihr vor viele unerwartete Probleme gestellt. Aber Dinge wie Integration sind komplex und zeitintensiv. Der Jury ist bekannt, dass ihr insbesondere was die Zeit angeht, keine Handlungsspielräume habt. Also sind Dinge wie Hacken, Tweaken, Hardcoden, Mocken, usw. in euren ersten MVPs erlaubt. Macht es einfach, wenn es euch schneller vorankommen lässt. Gibt es eine besonders schöne Lösung, die viel Zeit benötig, und eine nennen wir es „hässliche“ Lösung, die schnell umzusetzen ist? Wählt immer die weniger schöne. Ich empfehle ein Proof-of-Concept zu entwickeln. Solange ihr alles in einen späteren MVP wieder aufräumt, ist alles händelbar.  Die Juroren wollen eine funktionierende Lösung sehen. Sind einige Details noch nicht fertig, ist das keine große Sache. Aber spielt immer mit offenen Karten während eurer Präsentation. Wenn ihr eine Abkürzung genommen habt, sagt das der Jury. Vergesst nicht ihnen zu sagen, was angepasst werden müsste um eine echte Lösung für das Problem zu haben. Erzählt ihnen wie viel Zeit ihr dafür benötigen würdet.

Eure Präsentation ist extrem wichtig. Dort könnt ihr eure Arbeit den Wettkampfrichtern vorstellen. Bereitet euch gut vor. Sie ist mindestens so wichtig wie eure Lösung. Also fangt schon am Anfang des Hackathon mit ihrer Vorbereitung an. Ihr könnt sogar ein Teammitglied nichts anderes als die Präsentationsvorbereitung machen lassen. Gleich zu Beginn. Iteriert eure Präsentationsversionen, wie ihr euren Code iteriert. Ihr entwickelt MVPs eures Produktes. Ihr solltet auch MVPs eurer Präsentation erstellen. Und synchronisiert diese mit den MVPs eures Codes. So dass ihr jederzeit einfach mit dem Entwickeln aufhören und präsentieren könnt.

Wie ich oben bereits erwähnt habe, ist eure Präsenationszeit ist wirklich kurz (5 bis 10 Minuten inkl. Demos). Also lasst euch nicht ablenken. Fokussiert euch auf eure Vision. Zeigt in der Demo das eure Lösung funktioniert (Ich weiß, dass Live-Demos schwer sind. Also trainiert für sie. Bereitet Lösungen für Rückfälle vor). Lasst die Juroren merken, dass ihr euch wirklich Gedanken gemacht habt und sie eigentlich jede Rückfrage zu allen Themen stellen können und ihr die Antwort wisst. Macht eine gute Bühnenshow daraus. Auch das gehört dazu.

Ein Hackathon ist eine Teamleistung. Sucht euch drei andere Personen, mit denen ihr gut zusammen arbeiten könnt. Ihr seid immer unter Zeitdruck. Euer Team ist vielleicht sehr heterogen, mit unterschiedlichem, kulturellem Hintergrund, von verschiedenen Firmen, mit unterschiedlichem Vorwissen. Ihr müsst während des Wettbewerbs sehr eng zusammen arbeiten. Ob alt bekanntes oder neues Team, ihr werdet verschiedene Herangehensweisen an Probleme haben. Verbraucht nicht zu viel Zeit damit darüber zu diskutieren, wie man etwas am Besten macht. Alle Ansätze sind im Zweifel gut. Wählt einfach einen aus.

Manche eurer Ideen benötigen Vorbereitungen. Beispielsweise eine Cloud Foundry Installation oder einen Concourse server. Ihr braucht eine vom Tagesgeschäft unabhängige Umgebung, damit ihr flexibel und unbeeinträchtigt agieren könnt. Bereitet diese Umgebung vor. An dem einzigen Hackathon an dem ich teilgenommen habe und den ich nicht mit meinem Team gewonnen habe, brauchten wir zu viel Kram der vorbereitet werden musste bis wir mit dem Coden anfangen konnten. Also verbrachten wir die meiste unserer Zeit mit den Vorbereitungen bevor wir mit unserer eigentlichen Lösungen anfangen konnten. Diese Dinge sind nicht Teil eurer Beurteilung am Ende des Wettbewerbs. Also bringt sie zum Hackathon mit. Die Wettkampfrichter interessiert sich nicht für die Umgebung in der eure Lösung entwickelt wird. Also fokussiert euch auf euer Projekt und nicht auf die Entwicklungs- oder Testumgebung.

Fazit

Hackathons machen Spaß. Sie bringen neue Ideen und Erweiterungsprojekt für die Cloud Foundry Community. Im Team mit Menschen aus der ganzen Welt und von verschiedenen Firmen an einem Projekt zusammen zu arbeiten, hat mich in jedem Fall immer sehr bereichert. Ich hoffe meine Tips bringen Euch weiter und ich bin überzeugt, dass jeder die Chance hat zu gewinnen. Ich drücke euch in jedem Fall die Daumen und freue mich auf den nächste Hackathon.