Wir hatten drei Stunden Zeit und sollten in Vierergruppen arbeiten. Ich tat mich mit Sebastian Bergmann zusammen, eine natürliche Wahl angesichts der Tatsache, dass ich mit ihm unterwegs war und er einer meiner Geschäftspartner ist. Zu uns gesellte sich Carl Vuorinen, ein weiterer Sprecher auf der Konferenz. Wir vereinbarten, dass Carl den JavaScript-Frontend-Teil und Sebastian und ich den PHP-Backend-Teil übernehmen würden. Nach einer Weile stieß Jakub Gimiński zu uns, und begann, bei der Implementierung des Backends zu helfen. Mit Sebastian Bergmann und mir im Team war es ziemlich klar, dass wir eine vollständige Testautomatisierung anstreben würden, und nicht automatisch und von vorne herein ein komplexes Framework einsetzen würden.
Und hier ist das erste Problem: Sie befinden sich in einem Hackathon und haben drei Stunden Zeit, um die Aufgabe zu erledigen. Wie viel Zeit verbringen Sie nun damit, die Leute ins Boot zu holen? Richtig, nicht genug. Und da es vier Leute mit unterschiedlichen Betriebssystemen und PHP-Umgebungen waren, auf welche Umgebung einigt man sich? Sebastian und ich benutzten bereits PHP 7, aber die anderen beiden nicht. Außerdem sollten wir unsere Lösung auf einer Cloud-Plattform bereitstellen, ohne zu wissen, welche Umgebung sie unterstützen würde. Carl brauchte eine ganze Weile, um den Cloud-Server einzurichten, weil er sich mit der Oberfläche vertraut machen musste. Und erst gegen Ende wussten wir, welche Version von PHP die Cloud-Instanz bieten würde. Natürlich sind die Unterschiede zwischen den Minor-Versionen von PHP 5 eher subtil. Aber erst nach einem Drittel der Zeit zu wissen, wie unsere Zielplattform aussehen würde, fühlte sich für mich nicht richtig an.
Fahrt aufnehmen
Ein paar weitere Minuten wurden damit verbracht, Jakubs PHP-Umgebung auf „Standard“ zu bringen, zumindest auf das, was Sebastian und ich als Standard ansehen würden. Wieder fühlte ich mich gehetzt, denn das Ziel des Hackathons ist es, den Job zu erledigen, also fühlt sich alles außer dem Schreiben von Code wie Zeitverschwendung an.
Als ich an der API arbeitete, wurde mir klar, dass die Spezifikation fehlte: Wir sollten eine Methode implementieren, um einem Versandcontainer eine Tracking-Nummer zuzuweisen. Laut Spezifikation sollte diese Tracking-Nummer vom Kunden bereitgestellt werden. Das ergibt natürlich keinen Sinn. Je komplexer das Format einer Tracking-Nummer ist, desto schwieriger wird es für den Kunden, eine gültige Nummer einzugeben oder auszuwählen. Außerdem müssen wir die Einzigartigkeit sicherstellen, was schwierig ist, bevor wir sie tatsächlich speichern. Die Sicherstellung der Einzigartigkeit wird schnell unmöglich, wenn Sie ein verteiltes System betreiben müssen. Es wäre viel einfacher, wenn das System eine (gültige und eindeutige) Tracking-Nummer zuweisen würde, wenn der Kunde einen Container registriert. Dies ist die Lösung, die wir implementiert haben, und wir haben unsere Entscheidung und die Gründe dafür dokumentiert. Unsere Lösung befindet sich übrigens auf GitHub , wenn Sie einen Blick darauf werfen wollen.
Nach drei Stunden hatte Carl das Frontend erfolgreich implementiert, aber der Webserver war immer noch nicht richtig konfiguriert, was auch daran lag, dass wir uns für eine klare Trennung zwischen API und Frontend entschieden hatten, uns aber ein Hostname für unsere virtuelle Maschine fehlte. Mit nur einer IP-Adresse zwei verschiedene Sub-Domains einzurichten ... naja. Natürlich kann man den Webserver auch anders einrichten, aber das entspricht nicht dem, was wir gewohnt waren, sodass es länger dauerte als nötig. Wir waren auch nicht in der Lage, die API über HTTPS laufen zu lassen, wie man es sollte, weil wir kein Zertifikat hatten. Und das Importieren einer benutzerdefinierten CA in den Browser ...
Der ganze Hackathon fühlte sich an, als ob wir alle Probleme eines anständigen Projekts lösen würden, aber wir mussten alles überstürzen, weil die Deadline schnell näher rückte. Natürlich gab es Bier und Pizza, und wir waren uns alle sicher, dass wir das nicht machen, um zu gewinnen, sondern um Spaß zu haben und zu lernen. In der Zwischenzeit coachte Sebastian Jakub, der mit Unit-Tests nicht sehr vertraut war, beim Schreiben von Tests für die von ihm erstellten Wertobjekte. Ich hatte ein kleines „Framework“ zusammengeschustert, bestehend aus einer HttpRequest
- und einer HTTPRequestUrl
-Klasse, für die noch Tests fehlten, weil ich „keine Zeit hatte“. Ich war nahe dran, aber nicht in der Lage, meinen Code fertigzustellen und die Anwendung zum Laufen zu bringen.
Fast fertig
Am Ende hatten wir etwa 500 Zeilen anständigen PHP-Code, der nicht vollständig getestet war, aber alle vorhandenen Tests bestand. Carl hatte den JavaScript-Code mit AngularJS geschrieben. Es funktionierte. Oder zumindest hätte es „wirklich“ funktioniert, wenn wir vielleicht noch eine Stunde Zeit gehabt hätten, den Webserver in Stellung gebracht und alles integriert hätten. Tatsächlich hat Carl das Repository geforked (wir hatten beschlossen, den ursprünglichen Zustand beizubehalten) und die Software nach der Konferenz fertiggestellt.
Als ich ins Hotel zurückkehrte, wurde mir klar, dass der enge Zeitplan uns während des Hackathons gezwungen hatte, so ziemlich all das zu tun, von dem wir alle immer gesagt bekommen, dass wird es nicht tun sollen. Und dass wir gerade eine „echte“ Projektsituation erlebt hatten: eine knappe Deadline, nicht genug Kommunikation „weil wir keine Zeit haben“, überstürzte technische Entscheidungen wie die Verwendung von HTTP „weil wir keine Zeit haben“, Dinge schnell und schmutzig zu machen „weil wir keine Zeit haben“. Kommt das jemandem bekannt vor? Genau: die meisten Teams, die ich getroffen habe (und ich habe viele von ihnen getroffen), erleben genau das tagtäglich. Und es ist falsch.
Liebe Organisatoren dieses Hackathons: Ich danke Ihnen sehr, dass Sie diese Veranstaltung möglich gemacht haben und all die Mühe, die Sie in sie gesteckt haben. Es hat großen Spaß gemacht, und ich habe sehr, sehr viel gelernt. Es war eine unbezahlbare Erfahrung. Als Konsequenz daraus werde ich nie wieder an einem Hackathon teilnehmen, denn er zwingt uns dazu, so ziemlich alles falsch zu machen. Bei der Entwicklung von Software geht es nicht darum, möglichst schnell eine Menge Code zu schreiben. Wir müssen kommunizieren. Wir müssen uns darauf einigen, wie wir Dinge tun. Wir müssen alle auf dieselbe Seite bringen. Wir müssen bewusste Entscheidungen treffen. Wir brauchen Zeit, um die Anforderungen zu verstehen, und wir brauchen eine Feedback-Schleife, um sie zu klären, besonders wenn wir denken, dass sie fehlerhaft sind. Wir können niemals Kompromisse eingehen, wenn es um die Sicherheit geht. Wen kümmert es schon, ob unser Webserver sicher ist, wir hatten nur 15 Minuten Zeit, ihn einzurichten, und wer würde dank Cloud Computing jemals annehmen, dass es länger dauern könnte, darüber nachzudenken, wie die Live-Umgebung konfiguriert werden sollte.
Eher schädlich als nützlich
Hackathons sollten als schädlich angesehen werden. Sie lehren uns, genau auf die Art und Weise zu arbeiten, wie all unsere Erfahrung uns lehrt, dass wir nicht arbeiten sollten. Wie wäre es, stattdessen einen Dev-a-thon zu veranstalten? Geben Sie jedem Zugang zu einer vernünftigen Entwicklungsumgebung, und lassen Sie es für alle gleich aussehen. Es ergibt keinen Sinn, ein Drittel der Zeit des Hackathons damit zu verschwenden, technische Probleme auszubügeln. Ich bin mir durchaus bewusst, dass das Ausarbeiten von Macken und Problemen ein wesentlicher Teil des Lebens eines Entwicklers ist, aber ein Team von verschiedenen Leuten, die sich auf eine Entwicklungs- und Live-Umgebung einigen, braucht viel länger als eine Stunde (und im wirklichen Leben macht eine Stunde nicht ein Drittel der Projektdauer aus). Bereiten Sie die gleiche Live-Umgebung für alle vor. Bauen Sie absichtliche Fehler in die Spezifikation ein. Ermutigen Sie jedes Team, die Spezifikation zu hinterfragen und zu ändern, und dokumentieren Sie ihre Entscheidungen und die Gründe dafür.
Bitte beachten Sie, dass dieser Text weder eine Beleidigung gegen den Organisator des Hackathons bei Bulgaria PHP noch gegen den Organisator irgendeines Hackathons sein soll. Ich werde mich gerne zur Verfügung stellen, um Teams durch jede Dev-a-thon-ähnliche Veranstaltung zu coachen, die einen starken Fokus auf die richtigen Werte hat.