{devday.18}

Hier nun meine Mindnotes zum DevDay 2018. Was die Tracks jetzt gezielt mit dem Thema Digital Reality zu tun hatten sei erst einmal dahingestellt. Die Mischung aus technischen und “psychologischen” Themen war meiner Meinung nach in Ordnung, wobei mich tatsächlich die technischen Parts eher weniger angesprochen haben.

Den Einstieg gabs von fefe mit einer langen Version seines Vortrags zu Antipatterns in der Softwareentwicklung. Alles in allem nichts wirklich neues für jemanden der den Entwicklungsprozess in verschiedensten Teams erlebt hat. Im Kern aber ist die Aussage für mich, dass von oben gesteuerte und von Budgets eingeengte Softwareentwicklung gepaart mit der natürlichen Faulheit des Entwicklers eine explosive Mischung sind.

In der Folge habe ich mir den Vortrag von Dennis Traum, Vom Bildschirm in die Notaufnahme - Performance, Perfektionismus und Burnout in der IT, angehört. Ich muss zugeben der Inhalt war so nicht erwartet und hart an der Herzschmerz Grenze, aber sein Plädoyer: “Wenn es nicht Perfekt sein muss, kannst du es auch schaffen” spricht dem Agilisten in mir aus der Seele.

Weniger gefallen hat mir der Vortrag von Torsten Weber unter dem Titel: Mehr Hirn im Team, bitte. Torsten verlor sich ziemlich stark in grundlegenden psychologischen Theorien mit sanftem Bezug zu Entwicklungsunternehmen. Nett fand ich, das er sehr intensiv herausgearbeitet hat das die Herangehensweise von HR Abteilungen und Rekrutern zu stark dem Schema: “Zahl für das was im CV steht” tendiert. Weniger nett fand ich den Start von konkreten Tipps als er schon die rote Karte bekommen und die Pause angefangen hatte.

Bevor es in die Abschlusskeynote ging habe ich mir dann aus aktuellem Interesse den Vortrag zur Integration von Springboot und Hashicorp Vault angehört. Ein schöner Überblick über die verschiedenen Backends. Was für mich fehlte waren Gedanken wie Vault in vollautomatischen Deploymentprozessen für mehr Sicherheit sorgen kann.

Sicherheit war dann zum Abschluss das Thema von Thomas Haase der in seinem Vortrag Hack me if you can! aus dem Nähkasten der Pentester geplaudert hat. Ein schöner Abschluss, in jedem Fall besser als der Clown von Microsoft im letzten Jahr.

Der Orga kann ich nur danken, denn in Summe war der Besuch wieder lohnend, auch wenn das Gedränge bei Kuchen und Suppen ein klares Indiz für die Kapazität der Location in dieser Konfiguration ist.

DevDay 2018 - Digital Reality

Agile Meetup in den DWH

Ein Agile Meetup, mal nicht in einem IT-Unternehmen mit eifrigen Recruitern im Hintergrund. Gibt’s nicht? Gibt’s doch!

Der Einheimische erinnert sich sicher noch an Möbel aus dem Vorzeige Unternehmen, Deutsche Werkstätten Hellerau made in GDR. Heute fertigt das Traditionsunternehmen komplette Inneneinrichtungen für Luxusyachten und Häuser an. Dabei verfolgt man eine sehr offene Philosophie, ein großes Office, eine große flexible Werkhalle. Die Show der letzteren war natürlich ein haptisches Highlight, spannend war aber auch die Feststellung der Unternehmer das sie mit den aktuellen Prozessen an die Grenzen des Machbaren stoßen.

Am Anfang steht nicht mehr als eine fixe Idee. Oft nur eine Skizze aus der am Ende eine 180 Meter Yacht entstehen soll, ganz nach den Wünschen des Kunden. Zum festen Preis, zum festen Termin.

Im aktiven Part des Meetups ging es dann auch darum Ideen für den Start in die Agilität zu finden. Als Brainstorming Game kam 1-2-4-All zum Einsatz, womit gleich auch Liberating Structures am praktischen Beispiel demonstriert wurde. Spannend war am Ende der Outcome der doch bei vielen sehr in Ähnliche Richtungen ging:

  • Vorleben und Einführen von agilen Methoden in kleinen Teams
  • Schnelles Liefern von Prototypen
  • Experimentieren mit Methoden wie Kanban

Die zweite Session konzentrierte sich auf ein anderes Problem. Anett stellt die Frage in die Runde wie ein perfekter Moderationskoffer aussehen sollte. Für mich in Teilen war die Frage nur zum Teil interessant, denn meiner Meinung nach gibt es sowas wie den perfekten, standardisierten Koffer einfach nicht. Mir reichen Grundmaterialien, Schreibzeug, Stickies aus. Alles weitere liegt viel zu stark an den Nutzern.

Agile Meetup Dresden

Erfolg des Scheiterns

Neulich hörte ich eine These dazu, warum es in Israel so eine lebendige Startup Kultur gibt. In Israel so sagte der Interviewte, sei das Scheitern kulturell anerkannt und nicht verpönt wie hier in Deutschland.

Klar, sind wir hier doch schon von der Schule an auf maximale Leistung und beste Noten getrimmt. Willste den NC deines Traumstudiums schaffen müsste eben büffeln. Egal ob das gelernte einen probaten Mehrwert bietet oder nicht.

Klassischer Projektablauf nach Pflichtenheft und Wasserfall folgt ebenfalls diesem Prinzip. Alles muss vollständig geliefert werden. Egal ob die Hälfte eigentlich keinen echten Mehrwert liefert.

Agiles Vorgehen wiederum sieht das Scheitern als integralen Teil des Prozesses. Aus Fehlern kann man lernen, von daher sind sie auch nichts an sich schlechtes. Ein guter Scrummaster gar muss lernen sein Team Fehler machen zu lassen, selbst wenn er es eigentlich besser wüsste.

Und ganz tief am Boden unseres physischen Seins hat schon alte Darwin erkannt daß die ganze Evolution allein auf Fehlern basiert. Für das einzelne Gen ist es zwar total doof wenn es nicht überlebt, aber das gesamte System hat sich in der nächsten Generation verbessert, weil es eben ein bestimmtes Gen als Fehler erkannt und eliminiert hat.

Somit hat jeder Fehler seine Daseinsberechtigung, jeder Fehler hat durch zukünftige Vermeidung einen Mehrwert. Fehler in diesem Sinne also Grundlage von Erfolg im allgemeinen sind.

To squash or not to squash

Als Nutzer von GIT als Versionsverwaltung dürfte einem bewusst sein das die Historie nicht
in Stein gemeißelt ist. Commits können sowohl lokal als auch remote auf dem Server verändert
werden
. Eine recht verbreitete
Variante dieser Veränderung ist der “Squash”.

Tatsächlich kann man vortrefflich darüber streiten ob es sinnvoll oder vielleicht sogar
gefährlich ist die Historie in einem System zu verändern dessen elementare Aufgabe es ist
eben diese zu bewahren. Für mich ist der Squash in erster Linie ein Mittel um einen Feature-Branch
aufzuräumen, bevor dieser zurück in den master-Branch fließt.

Dabei ist es für mich ein absolutes No-Go blind sämtliche Commits zusammenzuführen nur damit die
Zahl der Commits gering gehalten wird. Wohl aber finde ich es sinnvoll über die Commits zu gehen,
eventuell logisch zusammenhängende Commits zusammenzuführen oder neu zu sortieren. Kleine Fehlercommits
ala “tippfehler korrigiert” interessieren im Nachgang auch niemanden.

Zwiespältig sehe ich das entfernen von Commits die einen Fehler produziert haben. Handelt es sich
um einen Flüchtigkeits- oder Tippfehler dann kann der mMn gerne weg. Bei Denkfehlern kann ein zweiter
Commit mit einer Korrektur und einem Hinweis auf diese vielleicht für einen Reviewer oder interessierten
Codeleser weiter helfen dieses Problem selbst zu vermeiden. Muss man also von Fall zu Fall entscheiden.

Was schon aufgrund technischer Gefahren nicht passieren sollte sind Änderungen der Historie auf dem
Master-Branch, oder auch auf Intergrations-Branches. Diese werden typischerweise von mehreren Entwicklern
verwendet, gar kontinuierlich geliefert und was geliefert wurde sollte sich nach der Lieferung auch
nicht mehr verändern.

Code Reviews

Pair-Programming ist allgemein eine ziemlich doofe Zielsetzung. Klar mal für ein Problem, oder ein Experiment mit dem Kollegen am Rechner kuscheln ist ganz nett. Längere Sessions ermüden mich persönlich allerdings doch schnell und es schleicht sich dann auch bald ein Gefühl der Ineffizienz ein. Dabei lernt man gemeinsam neue Technologie kennen, teilt direkt das Wissen und steigert die Qualität des Produktes. Ganz nebenbei lernt man auch den Stil und die Denk- und Arbeitsweise der Kollegen kennen. Gerade letztere können aber stark von der eigenen abweichen und damit sind Konflikte eigentlich vorprogrammiert.

Ich persönlich bin also eher nicht der Pair-Programming Typ. Die oben genannten Vorteile finde ich persönlich in einem eigentlich stärker qualitätsorientieren Verfahren wieder, dem: Code-Review.

Leider kannte ich Code-Reviews bis vor einiger Zeit Code-Reviews primär als zufälliges Ereignis, bei dem dann typischerweise ein Verriss des untersuchten Codes stattfand. Grund für diese Reviews war meist, ein beim Testen aufgetretener Fehler, der einen anderen Entwickler auf den Plan rief. Ergo war das Review unbeliebt und unproduktiv.

Die zweite Variante die ich kannte war das öffentliche Code Review mit Beamer und großem Auditorium. Dabei wurden dann meist komplexe Codes an die Wand geworfen und spätestens nach 10 Minuten wich die Stimme des Präsentierenden dem angenehmen Rauschen des Beamers, das irgendwann wiederum durch ein: “noch Fragen” jäh unterbrochen wurde.

Die Wirklich geile Version des Code-Reviews aber ist die, welche stetig durchgeführt wird. Stetig weil sie Teil einer Definition of Done ist und weil jede Codeänderung, egal ob Bugfix oder Feature, von mindestens einem zweiten Entwickler begutachtet wird.

Wie schon erwähnt funktioniert das nur in einer Umgebung die konstruktiv und objektiv zu arbeiten bereit ist. Nicht jeder Entwickler hat die gleichen Ansprüche und Voraussetzungen, daher muss beim Review klar sein, dass der Code des anderen durchaus in Ordnung sein kann auch wenn man ihn selbst so niemals geschrieben hätte.

Allgemein habe ich Code-Reviews in meinen letzten Projekten als sehr hilfreich erfahren und lieben gelernt. Zum einen lernt man so den Stil- und die Lösungsstrategien der Kollegen kennen, zum anderen lernt man neuen heißen Scheiß kennen. Auf jeden Fall hat man am Ende immer das Gefühl als Team ein besseres Ergebnis geliefert zu haben.

Klar fasst man sich manchmal dabei an den Kopf, wenn man merkt was man da für einen Schmarn geschrieben hat, oder wie umständlich der andere gedacht hat, diese Minuten des WTF-Gemurmels werden aber meines Erachtens durch Lerneffekt und Qualitätsgewinn mehr als aufgewogen.

Ein Allheilmittel ist das Code-Review natürlich nicht. Vor allem zu komplexe und umfangreiche Änderungen sind schlecht für Reviews geeignet, sind aber dann auch Anzeichen für andere Probleme im Entwicklungsprozess.