Mehr als Code - was gute Software-Entwickler bewirken können

Viele von uns haben ein bestimmtes Bild von guten Software-Entwicklern im Kopf: Sie tippen konzentriert vor sich hin, produzieren Code und arbeiten die Anforderungen eines Tickets ab: Ticket rein, Ticket raus - das war’s. Sie sind zuverlässig und produktiv und man hört oft nicht viel von ihnen. Soweit, so gut - aber wir sind überzeugt, dass sehr gute Software-Entwickler noch viel mehr als das sind. Und wir als Entwickler können viel mehr beeinflussen und verändern als nur den Code, den wir schreiben.

Wir sind Dan und Scott. In unserem Team arbeiten wir nach Scrum [1], weil das aus unserer Sicht die beste Möglichkeit ist, schneller mehr Wert zu liefern. Scrum ist die effektivste Art, die Produktentwicklung zu organisieren, wenn der Wert des Produkts und die Arbeit, durch die er geschaffen werden kann, noch nicht klar definiert sind. Habt ihr auch schon einmal einen ganzen Tag für eine einfache Code-Änderung gebraucht, weil sie einen unerwarteten Domino-Effekt ausgelöst hat? In solchen Fällen hilft Scrum dabei, Aufgaben neu zu priorisieren. Und durch die Definition of Done [2] weiß man immer, ob die Arbeit auch wirklich abgeschlossen ist. Damit stellen wir nicht nur sicher, dass wir nichts vergessen haben, sondern auch, dass unser Code den Qualitäts- und Sicherheitsstandards der restlichen Codebase entspricht. Deswegen schätzen wir diese Arbeitsweise sehr.

Ein Scrum Team besteht aus einem Product Owner, einem Scrum Master und mehreren Developern, die über die Fähigkeiten verfügen, das Produkt zu entwickeln. Wir schreiben hier aus der Perspektive der Developer. Jeder im Scrum Team ist für etwas verantwortlich, z.B. den Fokus zu bewahren, aber für uns als Developer geht es hauptsächlich darum, Dinge abzuschließen. Der Product Owner entscheidet, was wir tun, und wir sind dafür zuständig, herauszufinden, wie wir das umsetzen. Zu unserer professionellen Verantwortung gehört auch, dass wir regelmäßig nutzbare Increments [3] liefern, die unsere Definition of Done erfüllen (d.h. sie sind funktional, sicher, compliant, und lieferbar). Wir organisieren unsere Produktentwicklung in zweiwöchigen Sprints und liefern jeden Sprint mindestens eine neue nutzbare Version unseres Produkts (ein Increment) an echte Nutzer. Durch häufige Releases neuer Versionen können wir schneller Wert liefern und herausfinden, wie wir das Produkt weiter verbessern können.

Und jetzt kommt das, was sehr gute Software-Entwickler ausmacht. Sie können nicht nur den Code gestalten, sondern auch die Zusammenarbeit im Team und den Status quo der Software-Entwicklung. Normalerweise sieht der Workflow in der IT so aus: ein Entwickler beginnt mit einer Aufgabe, arbeitet alleine daran und versucht sie anschließend zu integrieren. Diese Herangehensweise führt oft dazu, dass die Integration länger dauert als die eigentliche Entwicklung: Pull-requests blockieren andere Tickets, haben unvorhergesehene Nebeneffekte oder verursachen sogar Merge Conflicts. Deshalb haben wir uns dafür entschieden, einen anderen Workflow auszuprobieren: Was wäre, wenn wir standardmäßig zusammen an Aufgaben arbeiten und nicht jeder für sich? Man könnte annehmen, dass es länger dauert, wenn zwei (oder mehr) Personen gleichzeitig an einer Aufgabe arbeiten. Wir haben aber festgestellt, dass weniger Multitasking zu mehr abgeschlossenen Aufgaben führt und deren funktionale und technische Qualität sogar noch besser ist. Das passt zu einem der wichtigsten Prinzipien der Wertschöpfung: stop starting and start finishing („Hört damit auf, Dinge anzufangen und fangt damit an, Dinge abzuschließen“). Am Anfang des Experiments waren wir besorgt, dass so viel Pair Programming (oder Ensemble Programming[4]) zu Erschöpfung führen könnte, doch das Gegenteil war der Fall. Gemeinsam Code zu schreiben, führt dazu, dass wir nicht nur für Code-Qualität und Wissenstransfer Verantwortung übernehmen, sondern auch für unsere Selbstfürsorge. Wir achten konsequenter auf Pausen und machen pünktlich Feierabend, während wir gleichzeitig mehr Done Increments in kürzerer Zeit liefern als jemals zuvor in einem anderen Team.

Ein weiteres Element unserer gemeinsamen Coding Sessions ist das digitale Whiteboard, das wir für den Austausch von Ideen nutzen. Wir waren bei komplexen Aufgaben schon oft der Meinung, dass wir alle den gleichen Plan für die Umsetzung im Kopf haben - nur um dann nach ein paar Zeilen Code festzustellen, dass unsere Vorstellungen meilenweit auseinanderliegen. Also ab ans Whiteboard, um die schwierigen Architekturentscheidungen zu treffen, bevor wir den Code schreiben, damit wir uns aufwändige Refactorings sparen können. Ein Beispiel: Wir haben ein Feature umgesetzt, bei dem die Nutzer eine E-Mail zur Aktivierung ihres Accounts bekommen. Anfangs dachten wir „Nichts leichter als das!“ und haben direkt angefangen, zu programmieren. Dann wurde uns die versteckte Komplexität bewusst: Was passiert, wenn der Nutzer den Link in einem anderen Browser öffnet, oder nachdem er bereits ausgeloggt war? Woher wissen wir, wer versucht, seinen Account zu verifizieren und ob sich dieser Nutzer schon authentifiziert hat? Uns war klar, dass wir den Usern für die Aktivierung eine Möglichkeit zum Login geben mussten, aber wir waren uns nicht einig über die beste Lösung. Einige waren der Meinung, dass wir einen Status nutzen sollten, um die Information zu persistieren, dass der Nutzer nach dem Login seinen Account verifizieren möchte. Andere wollten dafür einen URL Parameter nutzen. Auf einem Whiteboard haben wir Pro und Contra der beiden Optionen aufgelistet und kamen zu dem Schluss, dass wir das Beste aus beiden Welten bekommen, wenn wir unsere Login-Maske auch auf der Seite für die Aktivierung nutzen. So mussten wir weniger ändern, es gab ein geringeres Fehlerpotential und die Umsetzung war robuster. Wenn Software-Entwickler alleine an Aufgaben arbeiten, kommen diese verschiedenen Sichtweisen oft erst bei Code Reviews zum Vorschein. Und dann ist es normalerweise zu spät, noch grundlegende Änderungen vorzunehmen.

Ein weiterer Vorteil davon, zu zweit oder als Gruppe zu programmieren ist, dass wir dem Product Owner besser alternative Lösungen vorschlagen können. Ein Beispiel: Vor Kurzem sollten wir das SEO-Ranking einer Website verbessern. Unser ursprünglicher Plan war, die Codebase auf ein SSR Framework umzustellen, um ein besseres SEO Ranking zu erreichen. Wir hatten einen Sprint Zeit dafür und haben uns darüber ausgetauscht, welche Subtasks wir dazu brauchen. Uns wurde jedoch schnell klar, dass das eigentliche Ziel nicht die Umstellung auf SSR war, sondern die Verbesserung des Rankings. Also haben wir uns einen Nachmittag Zeit genommen, um zu recherchieren, wie wir unseren bestehenden Code SEO-freundlicher machen könnten - mit dem Ergebnis, dass wir dazu gar kein SSR brauchen! SEO hat sich mit der Verbreitung von Applikationen auf Kundenseite weiterentwickelt und es gibt viele Möglichkeiten, das Ranking auch ohne aufwändige Refactorings zu verbessern. Diese neuen Erkenntnisse haben wir mit dem Product Owner geteilt und ihm vorgeschlagen, unser Ziel ohne SSR zu erreichen. Nachdem wir ihn überzeugt hatten, machten wir uns an die Verbesserungen. Wir haben ein bisschen mit dem URL Inspection Tool gespielt, die HTML tags und robots.txt angepasst - und schon hatten wir das gleiche Ergebnis mit sehr viel weniger Aufwand erreicht. Das ist ein weiterer wichtiger Teil der Developer-Rolle, den jeder Entwickler ausfüllen kann: die Annahmen, wie ein Ziel erreicht werden kann, in Frage zu stellen und Alternativen aufzuzeigen. In unserem Fall wurde dadurch ein monatelanges Refactoring zu einer Aufgabe, die wir innerhalb von drei Tagen abschließen konnten. Das war nur möglich, weil alle im Team (auch wir als Developer) das Ziel im Blick behalten, auf das Fachwissen der anderen Teammitglieder vertraut und die DoD eingehalten haben.

An diesen Beispielen kann man erkennen, warum das verbreitete Konzept eines „guten Software-Entwicklers“ nicht mehr zeitgemäß ist. Ein Software-Entwickler ist nicht nur jemand, der Code schreibt. Entwickler tragen aktiv dazu bei, den Workflow zu optimieren, die Kommunikation zu verbessern und dafür zu sorgen, dass jeder im Team das Ziel im Blick behält, schneller mehr Business Value und einen Mehrwert für die Nutzer zu liefern. Software-Entwickler sollten die Möglichkeit haben und ergreifen, neue Ansätze für die Zusammenarbeit auszuprobieren. Unsere positiven Erfahrungen mit Pair Programming und Ensemble Programming zeigen, dass der Standard-Workflow nicht unbedingt die beste Alternative ist. Letztendlich entstehen Business Value und Mehrwert für die Nutzer in den Teams, die sie schaffen, und ein guter Software-Entwickler kann sehr viel mehr dazu beitragen als Code zu schreiben.

1: (https://www.scrum.org/learning-series/what-is-scrum/ - in englischer Sprache)
2: (https://amazing-outcomes.de/de/blog/nicht-done-kein-scrum)
3: (https://amazing-outcomes.de/de/blog/was-ist-ein-increment)
4: (https://en.wikipedia.org/wiki/Team_programming#Mob_programming - in englischer Sprache)