Transkript
Lucas: Hallo und herzlich Willkommen zu einer neuen Folge des INNOQ Podcasts! Heute sprechen wir über Reviews und dafür habe ich mir Gernot eingeladen. Hallo Gernot!
Gernot: Hallo Lucas!
Lucas: Magst du dich mal ganz kurz vorstellen für die Leute, die dich vielleicht noch nicht kennen? Wer du bist und was du so bei INNOQ machst?
Gernot: Gernot Starke ist mein Name, ich bin seit fast 10 Jahren INNOQ Fellow und seit so vielen Jahren, dass man gar nicht mehr fragen darf, in der IT – in der Software Architektur, Software Entwicklung – unterwegs. Habe Informationssysteme gesehen und entwickelt. Ja, ich glaube das ist es erstmal.
Lucas: Ja, aber ich glaube es gibt wirklich wenig Leute, die man da besser befragen kann zu Software Reviews als dich. Also lass uns doch einfach mal mit der ersten Frage starten. Wieso macht man das überhaupt? Also was ist die Motivation dazu, ein Software Review zu beauftragen oder überhaupt zu machen?
Gernot: Es gibt ja dieses Stichwort oder dieses Schlagwort: Jedes System hat Potential. Potential, das bedeutet ja im Klartext, da gibt es irgendwas, das ist suboptimal gelöst. Also irgendetwas. Das geht vielleicht ein bisschen besser. Also das System könnte schneller laufen, ein bisschen ergonomischer sein und mit Hilfe von Reviews oder irgendwelchen Betrachtungen des bestehenden Systems versetzen wir uns in die Lage, dieses Potential überhaupt zu finden. Also rauszufinden: Wo geht irgendetwas besser? Das ist halt aus meiner Sicht so die wichtigste Zielsetzung, die wir mit Reviews verfolgen. Der wichtigste Grund, warum wir halt Reviews machen.
Lucas: Okay und dann ist jetzt das, was jetzt vielleicht viele unter dem Review verstehen, dass man sich vielleicht ein bisschen Metriken anschaut, sich vielleicht anschaut, wurde sich an clean Code gehalten? Wäre das jetzt was für dich, wo du mit starten würdest in so einem Review? Wie siehst du das?
Gernot: Das sehe ich ja komplett anders! Also ich habe das erlebt. Ich durfte in meinem Leben auch Teams in Reviewprozessen, also in der Art wie man reviewt, coachen. Und ich kann mich halt erinnern, dass ich zu einem solchen Team gekommen bin, die steckten halt mitten in einer Code Analyse drinnen. Und ich habe dieses Team gefragt: Was macht denn überhaupt das System, das ihr da gerade reviewt? - Ja, wissen wir nicht. Ich war dann völlig verwundert: Wie könnt ihr Code von irgendetwas analysieren, wenn ihr nicht mal wisst, was dieses System denn überhaupt tun soll? Nicht mal wisst… Nicht mal eine Spur, eine Ahnung habt, was die Anwendungsfälle, was die Funktionalität, die Qualitätsanforderung und so weiter für dieses System sind. Dann guckten die ein bisschen betreten. Ja und genau das ist halt der Punkt. Mein Vorschlag ist, dass wir systematisch Reviews machen, wir definitiv vorher, also bevor wir anfangen, wild irgendwas zu untersuchen, zu analysieren und zu messen, mal mit verantwortlichen Menschen, das könnte Management sein, könnte Entwicklungsleitung sein oder auch Endanwenderin/Endanwender sein, mal drüber zu reden: Was sind überhaupt die Ziele dieses Reviews? Also was wollen wir denn mit diesem Review überhaupt erreichen? Also so dieses vorher mal drüber reden, was könnten denn mögliche Ergebnisse sein. Das lässt mich ja auch viel besser abschätzen: Was habe ich überhaupt für Maßnahmen-Möglichkeiten. Also wenn mir jemand sagt: Ich will die Defizite in meinem Code finden. Dann ist das mit dem in den Code gucken und…
Lucas: Genau.
Gernot: …metrisch rangehen und statische Analyse machen eine super Sache. Aber wenn mir jemand sagt: Ich möchte gerne die Zukunftssicherheit meines gesamten Systems überprüfen, dann reicht mir Code nicht aus alleine. Dann gibt es noch ein paar andere Untersuchungsbereiche.
Lucas: Okay, also die Untersuchungsvoraussetzungen, die werden wir gleich nochmal ganz in Ruhe besprechen. Bevor wir das machen: Wer macht denn überhaupt so ein Review? Was sind die Vor- und Nachteile, wenn man das vielleicht selber macht oder jemanden beauftragt?
Gernot: Ja, du kennst das ja bestimmt auch von dir selbst, Dinge, die du selbst entworfen hast, wo du selber Hand angelegt hast, die hast du ja aus Gründen so gemacht, wie du sie gemacht hast. Also eben, weil du das gut findest. Darum ist das manchmal ein bisschen fragwürdig oder schwierig, wenn Menschen ihre eigenen Dinge reviewen. Bei dem klassischen Code Review, da nimmt man ja möglicherweise eben aus diesem Grund jemand anders mit dazu. Jetzt ist das aber auch so, dass ich als internes Entwicklungsteam, also wenn ich, wenn wir das System selbst gebaut haben: Wir kennen uns natürlich mit Abstand am besten mit diesem Ding aus. Das hat bei Reviews halt auch einen Vorteil. Dieses, es gibt keine Einarbeitungszeit, man muss jetzt nicht erst noch so eine Einarbeitungsphase oder sowas einplanen, sondern ich könnte halt direkt starten. Wenn ich auf irgendeine Detailfrage stoße, dann bin ich als internes Entwicklungsteam möglicherweise total gut vernetzt und kenne diese Expertin und Experten, die sich mit diesem Detail super gut auskennen. Dafür gibt es aber das Risiko dieser Betriebsblindheit. Wir haben das ja als Entwicklungsteam vielleicht so gebaut, weil wir das ja gut finden. Der Review soll das aber hinterfragen, darum ist das eben manchmal gut, die interne Review zu ergänzen durch so eine Außensicht, also durch eine Meinung von außen. Das muss ja nicht immer jemand sein, der von ganz, ganz außen kommt. Es hilft ja dann oft auch mal, jemanden aus einem anderen Entwicklungsteam vielleicht in der gleichen Firma, in der gleichen Organisation, mit dazu zu ziehen. Einfach mal eine unabhängige andere Meinung zu kriegen auf die Sachverhalte, die wir halt im System umgesetzt haben. Darum finde ich das immer gut, wenn wir Review Teams mischen aus intern und extern. Also wir als INNOQ, wir arbeiten ja ganz als Externe. Wir haben halt den Vorteil, dass wir Branchenvergleiche machen können, branchenübergreifende Vergleiche und sagen können: Hör mal, euer System ist in dem Bereich, keine Ahnung, Performance bestimmter Use Cases deutlich schneller als vergleichbare Systeme, die wir in anderen Branchen kennengelernt haben. Also da ist das irgendwie ganz schön, wenn man intern und extern mischt, weil man dann eben die Nachteile, Externe müssen sich einarbeiten, ausgleichen kann aber alle Vorteile bekommt.
Lucas: Das finde ich tatsächlich auch einen wichtigen Aspekt vom Consulting generell, dieses Feedback zu bekommen: Andere Firmen haben dieses Problem, was ihr habt auch. Also ihr seid nicht die Einzigen, die dieses Problem haben. Sondern einfach zu hören: Ah okay, das ist sowas, wo verschieden Firmen mit Probleme haben. Das hilft den Leuten auch zu sehen: Okay, wir machen nicht alles schlecht. Also es geht ja auch nicht darum irgendwie zu sagen: Euer System ist schlecht! Sondern einfach einzuordnen, an welchen Stellen könnt ihr besser sein, aber an welchen seid ihr vielleicht auch schon sehr, sehr gut? Und das auch mal anzuerkennen, dass man vielleicht ein sehr schön wartbares System gebaut hat oder so. Das finde ich auch sehr wichtig.
Gernot: Ja, sehr schön, dass du das ansprichst, Lucas! Der Review findet halt auch Dinge, die man loben sollte. Also die ein Entwicklungsteam auf jeden Fall beibehalten sollte. Selbst wenn in der Kaffeeküche irgendjemand meckert und sagt: Da, an der Stelle, das ist ja ganz miserabel. Aber vielleicht ist das ja in Wirklichkeit super und nur diesen einem Menschen gefällt da der Coding Style an der Stelle nicht. Dann sollte ein Review auch eben zur Aufgabe haben, solche positiven Aspekte zu finden.
Lucas: Absolut!
Gernot: Also, um auf deine Frage zurückzukommen: Wer soll das denn machen? Die perfekte Besetzung wäre: 1–2 Leute aus dem Entwicklungsteam selbst und 1–2 Leute, die woanders herkommen. Diese Vor- und Nachteile dieser beiden Gruppierungen da miteinander zu verbinden.
Lucas: Ja, das finde ich eine sehr schöne Idee! Also du hast schon gesagt, wir wollen so ein bisschen damit starten, erstmal herauszufinden: Was ist denn das Ziel von unserem Review? Was sollen wir überhaupt machen? Nach was fragst du die Stakeholder denn noch so am Anfang? Also was sind so die Fragen, die du denen stellst?
Gernot: Ja, ich gehe jetzt mal einen halben Schritt zurück. Eine Frage, die ich gerne relativ früh oder ganz früh in so einem Review beantwortet haben möchte, ist: Welche Stakeholder gibt es denn überhaupt? Also mit welchen Menschen sollten wir denn reden? Oder welche Menschen sind denn überhaupt betroffen? Das beginnt ja oft bei den, ich nenne sie jetzt mal Fachbereiche, und beim Business oder bei irgendjemandem, der überhaupt eine Anforderung stellt oder ein Problem hat, das wir dann mit so einem IT-System lösen. Und auch solche Menschen würde ich ja gerne im Rahmen eines Reviews nach ihren Eindrücken fragen, ob sie Probleme haben oder ob ihnen irgendwas besonders gut gefällt oder so. Ich würde erstmal rausfinden: Wer sind die Stakeholder? Und dann im nächsten Schritt würde ich versuchen mit so einem repräsentativen Querschnitt dieser Stakeholder-Gruppen, also mit jemandem vom Fachbereich, mit jemandem aus dem Management, mit 1–2 Leuten aus dem Entwicklungsteam von Architekturseite, aber auch, vielleicht gibt es ja eine Qualitätssicherungsgruppe, eine eigene Testabteilung, eine Hardware Gruppe, die halt noch Hardware lötet oder so, mit denen wir auch was zu tun haben. Also mit denen würde ich halt querschnittig gerne mal reden. Ja, um rauszukriegen: Was stört? Wo gibt es halt bekannte Haken und Ösen? Gibt es da irgendwas, was besonders schwerfällig ist? Wo, ja wo man schon weiß: Hier auf den Knopf darf ich aber montags nicht drücken. Wenn ich montags da draufdrücke, dann geht immer folgendes schief… Das sind halt Dinge, die man durch Gespräche mit Stakeholdern, also mit den betroffenen Menschen total gut rauskriegt. Ja, bis dahin brauche ich dann nicht mal in Code geguckt zu haben. Also da reichen schon einfach Gespräche. Nicht einfach. Man muss ja die Leute erstmal finden. Die haben möglicherweise wenig Zeit oder auch keine Lust mit irgendwelchen komischen Reviewern zu reden. Aber das finde ich, ist eine supergute und sehr, sehr effiziente Quelle an Wissen, wo man halt so mögliche Potenziale, die es zu verbessern gäbe, auch gut finden kann.
Lucas: Bevor wir jetzt in so verschiedene Bereiche, die wir betrachten könnten: Wie siehst du das denn? Ist so eine Review eher eine Breitensuche oder eine Tiefensuche? Wie würdest du das einordnen?
Gernot: Die klassische Antwort, kommt drauf an, können wir hier an der Stelle tatsächlich außer Kraft setzen. Du hast die beiden, also beide Optionen genannt: Breite oder Tiefe. Mein Vorschlag ist definitiv: Breite vor Tiefe. Weil ich mehrmals selber kurz davor war oder auch mal reingefallen bin in, ich nenne es gerne die Mikroskop Falle. Also wir haben halt wirklich sehr low-level im Maschinenraum im Code ein paar Dinge gefunden, die uns sehr gestört haben. Wo wir gesagt haben: Hey, das kann man viel, viel geschickter lösen, kann man viel einfacher lösen. Aber es ist halt sehr low-levelig. Ja und dann, jetzt mal ganz flachs gesagt, schrauben wir an Details und die Mikroskop-Falle ist halt genau: Ich bin mit meinem Mikroskop im Detail und ich finde dort auch ein Problem oder Probleme, aber mit dem Blick auf das große Ganze ist dieses Problem total zu vernachlässigen. Also es besteht, wenn ich in diese Mikroskop-Falle tappe, das Risiko, dass ich da an Dingen rummäkele oder auch dann an Dingen anfange zu verbessern, wo es überhaupt nicht lohnt. Also wo es beispielsweise viel geschickter wäre, diese Komponente in Ruhe zu lassen, weil wir viel größere Probleme an anderen Stellen haben. Ich kann mich an einen Review erinnern, da ging es um so ein Content Management System. Ich war Teil eines Teams, das sich sehr mit Technik beschäftigt hat. Ich durfte aber auch ein paar andere Dinge angucken. Also ich hatte halt im Vorfeld gefragt: Was sind denn Review-Ziele? Und dieses Team, also das war ein anderes Unternehmen, das sich halt sehr mit Technik und Code beschäftigt hat, die hatten so… Für ein Content Management System ist das wichtig, wie kommt eigentlich der Content in dieses System? Also wie kommen da Dokumente und Inhalte und so weiter, wie kommt das halt zustande? Und mir ist dann in einem weiteren Review Schritt aufgefallen, dass der Prozess wie der Content in das System kommt, der war total kaputt. Also da gab es ewige Warteschlangen, wo Content dann quasi versauert ist, bevor er in dieses System kam. Und das hätte man technisch überhaupt gar nicht lösen können, sondern da musste man halt an dem Prozess ein bisschen schrauben. Ja, wenn man zu sehr technikverliebt ist, dann schraubt man halt an der Technik, aber löst einfach dieses große Problem nicht, den Content in das System zu bekommen. Und an den Stellen müssen wir als Techi wirklich sehr darauf achten, ab und zu mal aus dieser Mikroskop-Sicht eher in so eine Helikopter-Sicht zu kommen, um rauszufinden: Mensch, gibt es vielleicht noch ein paar andere Problembereiche, wo es viel gravierendere Dinge zu verbessern gibt?
Lucas: Eine von den Sachen, die mir da bei der Helikopter-Sicht direkt zuerst einfallen würde, wäre ja irgendwie Abhängigkeiten zwischen Teilsystemen. Welche Sachen würdest du dir da anschauen in so einem Review?
Gernot: Das ist ein ganz, ganz guter Punkt: So die Dependency-Analyse, Abhängigkeitsanalyse. Das ist einerseits etwas, was ich natürlich, solange ich eine geschlossene Code-Basis habe, auch ganz gut auf dieser einen Code-Basis machen kann. In verteilten Systemen ist das dann schon wieder schwierig, weil da oft in den verteilten Systemen Abhängigkeiten erst zur Laufzeit ausgenutzt werden oder sie überhaupt erst zur Laufzeit auftreten. Also da muss ich wirklich schon aus meinem einen Code-Fragment irgendwie rausgucken. Es sei denn ich habe jetzt einen Monolithen, also so eine riesengroße Java-Anwendung, da kann ich praktisch alle Abhängigkeiten durch eine Code-Analyse, durch eine statische Code-Analyse finden. Aber gerade in so Microservices oder self-contained systems, verteilten System-Komplexen, also wo Systeme aus ganz vielen einzelnen, ja zur compile-Zeit erstmal unabhängigen, aber zur Laufzeit abhängigen Dingen besteht, da wird dann so eine Abhängigkeitsanalyse schon anspruchsvoll, weil ich dann möglicherweise auch dem System zur Laufzeit auf die Finger gucken müsste. Und Abhängigkeiten, dass wissen wir alle, Abhängigkeiten brauche ich natürlich, weil ich nicht alles immer selbst in meinem eigenen Teilsystem implementieren will, aber zu viele Abhängigkeiten machen mich halt beim Entwickeln, beim Deployen, beim Testen und so weiter halt brutal langsam. Also das ist halt so ein zweischneidiges Schwert. So wie Feuer kann man zum Kochen brauchen, kann man seine Bude mit abfackeln und Abhängigkeiten sind halt genauso. Die wir aus der Architektur Sicht sehr kontrolliert einsetzen müssen, aus der Review Sicht ist das dann schon so ein Kandidat, wo man hinterfragt: Brauche ich diese Abhängigkeiten wirklich? Habe ich hier vielleicht so eine Art Gott-Komponente? Alles ist von dieser Gott-Komponente abhängig und wenn man die ändert, dann bricht überall woanders ganz viel zusammen. Ja, sowas ist schon wichtig auch in Reviews rauszufinden, ob es solche unerwünschten, weil viel zu engen Abhängigkeiten, Kopplungen, gibt.
Lucas: Ich meine, wenn man jetzt die Münze umdreht, die andere Seite der Münze von Abhängigkeiten von Systemen, sind ja immer so Prozesse im Unternehmen. Also welche Prozesse gibt es zwischen Teams? Wie werden Abhängigkeiten gemacht? Schaust du dir sowas auch in einem Review an oder beschränkst du dich auf Technologie?
Gernot: Genau. Du hast ja eben schon die Frage nach Breiten vs. Tiefensuche gestellt, die ich mit Breitensuche beantwortet habe. Das geht ja schon in die Richtung. Also ich möchte ja definitiv sowas wie Prozesse angucken. Ich habe tatsächlich in Reviews Systeme gefunden, wo ich technisch praktisch keine nennenswerten Verbesserungsvorschläge hatte. Ich habe aber nirgendwo, vielleicht lag das einfach an meiner komischen Review, die ich machen durfte, aber ich habe nirgendwo Entwicklungsprozesse gefunden, wo ich nicht irgendwie Vorschläge hätte wie: Hier kann man etwas effizienter gestalten vom Prozess her gesehen. Also ganz häufig habe ich erlebt, der Weg der Anforderung von den Menschen, die die Anforderung selber haben, bis zum Entwicklungsteam, der ist oftmals unglaublich verschlungen über Schleifen, über Hin- und Herschieberei. Dann gibt es Gremien, die Prioritäten für Anforderungen vergeben, dauert alles ewig lange und dann wird auf dem Entwicklungsteam rumgehackt: Ihr programmiert aber nicht schnell genug. Das kriege ich doch nicht technisch gelöst. Also da kann ich den Leuten noch einen schnelleren Prozessor kaufen und noch einen besseren Bildserver hinstellen, das nützt alles überhaupt nichts, solange dieser, Entschuldigung, völlig vermurkste Anforderungsprozess nicht mal ein bisschen gestreamlined wird. Da haben wir wirklich zahlreiche Beispiele in der Realität, also in kleinen und großen Organisationen gefunden, wo man an solchen Stellen viel, viel größere Hebel hat, Dinge zu verbessern. Also wo Reviews so Prozessdinge aufgedeckt haben, die halt wirklich interessant waren. Also von daher, wenn ich die Möglichkeit habe, das mit unserem Mandanten so abzusprechen, dann würde ich unbedingt in solche Prozessthemen reingucken. Und wirklich Ende zu Ende. Also von den Menschen, von den Abteilungen, die die Anforderungen haben, bis hin in die Betriebsübergaben. Also bis die Software wirklich im Betrieb oder in der Cloud irgendwo dann läuft.
Lucas: Und so im Bereich Technologie, also welche Technologien eingesetzt werden, welche Datenbanken, Datenstrukturen eingesetzt werden, was siehst du da so im Review?
Gernot: Ja, da hören wir natürlich schonmal öfter: Das setzen wir schon lange so ein. Also diese Technologie, dass ist hier halt bei uns so. Also Hashtag ISSO, ist so. Wo ich mich dann schon manchmal gefragt habe: Ja, das mag sein, dass ihr das schon lange so einsetzt, aber ihr habt schon gehört, dass es da auch… also beispielsweise in dem Bereich Datenbank. Jetzt kann ich natürlich in eine klassische relationale tabellenorientierte Datenbank in so BLOBs alles Mögliche Zeug packen, was ich nicht weiter strukturieren will, aber da sind schon seit ein paar Jahren auch andere Kategorien von Datenbanksystemen auf dem Markt, die einfach mit solchen unstrukturierten Dingen signifikant besser umgehen können. Und ja, das nutzen wir hier nicht. Dann frag ich… Sowas habe ich halt gehört. Dann frage ich mich: Ja, warum nutzt ihr das nicht? Und da sind Reviews eine gute Gelegenheit, auch Vorschläge zu machen und zu sagen: Mensch, im Bereich Persistenz, also euer Source Code, der sieht ja eigentlich ganz gut aus, aber die darunter liegende Basistechnologie, die ist halt vielleicht etwas in die Jahre gekommen. Ja, ich weiß, dass sind dann vielleicht auch betriebliche Aspekte oder wir kennen uns mit dem Management von so relationalen Datenbanken gut aus, wir haben da Backup-Prozesse für, aber die Technologie ist vielleicht nicht für alle geeignet. Und Datenbanken sind jetzt wirklich nur ein Beispiel.
Lucas: Ja. Ich finde Datenbanken aber an der Stelle auch ein gutes Beispiel für einen Bereich wo manchmal auch aus Prinzip das modernere eingesetzt wird. Also Stichwort Cassandra beispielsweise, dass dann als Unternehmenstechnologie gesetzt wird und das ist etwas, wo ich auch manchmal von Kollegen zu gefragt werden, ob das jetzt eine gute Datenbank für den Use Case ist. Da sehe ich auch oft den gegenteiligen Effekt, dass dann aus Prinzip etwas Neues benutzt wird.
Gernot: Ja. Das ist ja ganz spannend, also wo jetzt so hippe Technologie im Einsatz ist, aber man die halt überhaupt gar nicht beherrscht. Also da sind uns ja auch schon Unternehmen begegnet, die zwar supermoderne Datenbanksysteme einsetzen, aber niemals jemand mit diesen hypermodernen Datenbanksystemen das Backup Konzept getestet hatte. Und da muss ich schon sagen: Man kann halt auf dünnem Eis bestimmt auch Schlittschuh laufen, aber ich würde das lieber nicht tun wollen. Also schöner Punkt, dass man eben nicht nur überalterte Technologie findet, also mit der man einfach große Effekte, positive Effekte erzielen könnte, wenn man sie modernisiert. Sondern eben auch den umgekehrten Fall: Ihr bewegt euch da in einem Bereich, der einfach noch nicht… ja, den ihr noch nicht gut genug im Griff habt oder der vielleicht für euer System einfach noch ein Stück zu modern ist.
Lucas: Genau. Ein wichtiger oder zwei wichtige Aspekte, die ich da immer noch sehe, sind so der Bereich Security und Performance. Guckst du dir das auch an in der breiten Suche?
Gernot: Jein. Jein deswegen, weil ich zu Security deswegen nein sage, weil ich mich damit nicht gut genug auskenne. Also meine Hauptannahme ist: Security kennen die Angreifer besser als ich. Also wenn das Thema Security irgendeine Relevanz besitzt und das besitzt es in Informationssystemen in der Regel, schlage ich vor, jemanden dazu zu holen, der sich genau damit auskennt. Also macht nicht eure Security Reviews selbst! Da wir beide hier miteinander reden, Gernot sagt an der Stelle: Ne, macht eher nicht, sondern holt da irgendjemand die oder der sich auskennt. Performance ist ein super Thema, weil ich kann halt mit clean Code grottenschlechte Performance erreichen. So, wenn ich mich halt jetzt nur darauf beschränke, Code anzugucken und Abgängigkeiten anzugucken, dann werde ich möglicherweise Performancedefizite nicht finden. Wenn ich mit ein paar Stakeholdern gesprochen habe, dann haben die mir wahrscheinlich schon gesagt: Mensch, diese Query oder dieser Report, der ist aber elendig grottenlangsam. Das heißt, ich weiß dann schon ein paar Stellen, an denen ich mal gucken würde. Und dann können wir entweder mit Profiling-Mitteln oder aber auch gerade in Datenbank, in Netzwerkkommunikation und so weiter schon auch detailliert reinschauen, ob denn dieses eigentlich immer wichtige Qualitätsmerkmal Performance irgendwie suboptimal gelöst ist oder was für Potentiale es da an den Stellen gibt. Performance ist ja an der Stelle auch nur eine Ausprägung dieses generellen Begriffes qualitative Analyse. Also es gibt ja noch außer Security Performance noch einen Stapel weiterer Qualitätseigenschaften, auf die man gucken könnte. Das bringt uns jetzt zu weit an der Stelle, diese ganzen ISO Qualitätsanforderungen aufzuzählen, aber das ist definitiv auch ein Punkt, der zu so einem Review dazugehört.
Lucas: Also ein Aspekt von dem, wo ich vom Markus Harrer, unserem Kollegen, schon viel zu gehört habe, ist die Hotspot Analyse, die da vielleicht auch noch eine Rolle spielt. Kannst du dazu kurz etwas sagen, was das ist und wie du das einschätzt?
Gernot: Ja, dazu überlegen wir mal: Wir habe ja, wenn wir Entwicklungsprojekte, Entwicklungen angucken, dann ist ja unser Code seit Jahren immer rüttelsicher gespeichert in irgendwelchen Versionskontrollsystemen. Und so ein Versionskontrollsystem, ich habe da auch wirklich auch jahrelang den Fehler gemacht und die einfach als ein gutes Backup betrachtet. In Wirklichkeit verbirgt sich aber in einem Versionskontrollsystem ein unglaublicher Schatz, der für Reviews interessant ist. Nämlich das Versionskontrollsystem sagt mir wie häufig Dinge geändert wurden. Also das sagt mir, welche Artefakte, welche Dateien sind ganz, ganz oft angefasst worden. So, warum ist diese Frage interessant? Weil Dinge, die ich häufig anfasse, an denen ich häufig manipuliere, häufig ändere, da ist die Chance größer, dass ich beim Ändern aus Versehen etwas kaputt mache. Rein statistisch gesehen machen wir halt in der Entwicklung ein paar Prozent Fehler. Und wenn ich Dinge häufig ändere, ist meine Fehlerhäufigkeit dort höher. So. Diese Aussage in der Hotspot Analyse kombiniere ich jetzt mit der Untersuchung, wie komplex oder wie kompliziert sind meine Artefakte? Denn das wissen wir auch, in hoch komplexen Systemen ist die Chance, dass ich beim ändern etwas falsch mache höher als in einfachen Systemen. Also wenn ich so ein Hello World like Stück of Source Code habe, da macht kein Mensch irgendwas dran falsch. Also da muss ich schon angetrunken sein, um da irgendetwas falsch zu machen. Wenn ich aber Code habe, so achtfach geschachtelte if-else-Kaskaden noch mit ein bisschen reflection dabei, da ist die Chance, dass ich da einen Fehler mache total hoch. Und die beiden Sachen, die kombinieren wir jetzt. Änderungsfrequenz aus der Versionsverwaltung mit der Komplexitätsuntersuchung im Source Code. Und Dinge, die besonders komplex sind und häufig geändert werden, das sind Kandidaten für Verbesserung, also für Vereinfachung, für das Auseinandernehmen, in kleinere Teile zerlegen, wirklich auf Einfachheit optimieren. Weil wir aus der Versionsverwaltung wissen: das Ding wird häufig angefasst. Das ist wirklich eine ganz spannende Art der Untersuchung, die man heute auch mit ganz viel Open Source Unterstützung relativ einfach machen kann.
Lucas: Ja. Was ich persönlich da auch eine interessante Kombination finde, ist, eine niedrige Änderungsfrequenz und eine hohe Komplexität, weil das ist manchmal so der Hinweis, dass die geniale Entwicklerin oder der geniale Entwickler, der das entwickelt hat, ist nicht mehr da und keiner traut sich mehr, diesen Code anzufassen, weil der ist so komplex und kompliziert. Aber er funktioniert ja, das finde ich auch mal eine interessante Kombination.
Gernot: Ja, da müsstest du halt genauer reingucken. Beispielsweise mit dem betroffenen Entwicklungsteam einfach kurz Rücksprache halten, sagen: So, ihr habt Komplexitätsausreißer nach oben, also wo eure, möglicherweise zyklomatische Komplexität, die ihr messt oder Einrückungstiefe, die wir messen total ausreißt nach oben. Könnt ihr mir erklären, warum ihr das nie anfasst? Also ich kann mich erinnern, dass ich dann mit einem Team gesprochen habe, die gesagt haben: Ja, das ist einfach fertig. Das ist so ein Algorithmus, der irgendwas tut und der ist fertig und da gibt es auch keine Änderungen dran. Dann kann ich das wirklich in einer Untersuchung auf Seite schieben und sagen: Okay, das ist durch Testfälle abgesichert, kein Fachbereich beschwert sich darüber, dann ist das halt komplex. Dann kann man das auch durchaus so lassen. Umgekehrt haben wir halt wirklich auch in eigenen Reviews Teile in Systemen gefunden, die von der Komplexität gar nicht so schlimm waren, also jetzt nicht totale Ausreißer nach oben, aber dafür jede Woche und das über Monate, ständig angefasst wurden. Und wenn man dann in die Fehlerdatenbank guckt, gab es auch eine größere Anzahlt Fehler, die sich genau auf diese Komponente bezog. Das ist ein schönes Review Ergebnis, wenn man dann einfach einen guten Kandidaten, gute Kandidaten für Subsysteme oder Komponenten hat, wo man sagt: Hier würde sich verändern, also verbessern, vereinfachen wirklich lohnen, wirtschaftlich lohnen.
Lucas: Das heißt, du schaust dann auch in das issue tracking rein, um zu schauen, in welchen Bereichen viele Fehler auftreten, höre ich da so ein bisschen raus?
Gernot: Das ist doch ein super Potential an Informationen! Fehler-Cluster, da gibt es diese altbewährte achtzig-zwanzig Regel, achtzig Prozent der Fehler kommen aus zwanzig Prozent der Komponenten oder Subsystemen. Und das wäre schon fast ein Anfängerfehler, das nicht zu tun, also nicht mal zu gucken: So, was hattet ihr im letzten halben Jahr denn überhaupt für Fehler? Also was für Fehler sind aufgetreten? Wodurch wurden die verursacht? Klar, es mag halt einfach Bedienfehler geben, also wo jemand ein issue gemeldet hat, weil der Mensch einfach nur auf die falschen Tasten gedrückt hat oder so. Aber die, die dann wirklich übrigbleiben, also als echte durch das System verursachte Fehler, da lohnt es sich schon reinzugucken. Auch da gehen wir mit Stakeholdern in einem Interview artig einfach mal durch die letzten 50–100 bekannten issues durch. Das geht oft erstaunlich schnell, man hängt dann halt an 5–6 wo man sagt: Oh, das ist aber was ganz Spezielles! Und du merkst halt in so einem Durchgehen: Oh, das ist schon wieder die Komponente X/Y, die da das verursacht hat. Da muss man dann vielleicht bei Komponente X/Y auch mal genauer in den Code gucken.
Lucas: Ja, okay.
Gernot: Adjustments auch auf jeden Fall.
Lucas: Ja, das finde ich einen sehr guten Hinweis, auch wenn es vielleicht… Du sagst das ist ein Anfängerfehler, ich glaube den habe ich auch schon gemacht. Wenn wir jetzt…
Gernot: Ja, das ist halt, sorry, wenn ich deine Frage unterbreche, das ist halt dann dieses Dilemma: Wenn wir nicht systematisch auf diese Breite unserer Suche achten. Also wenn wir sagen: Ach, ja super, ich habe jetzt im Code schon drei Fehler gefunden, dann habe ich ja schonmal was. Nein, selbst wenn ich dann schon ein paar Fehler gefunden habe, möchte ich trotzdem gerne noch weitersuchen, eben zum Beispiel im issue tracker oder in der Datenbank oder in den Test Cases, Testfällen, Testdaten, Testumgebung, ob es da vielleicht auch noch Dinge gibt.
Lucas: Ne, das finde ich einen sehr guten Hinweis. Also jetzt haben wir eine große Breitensuche gemacht, haben ganz viele Sachen festgestellt. Jetzt müssen wir irgendwie dem Auftraggeber oder der Auftraggeberin die Resultate kommunizieren. Was hast du denn da für Tipps oder was hast du da für Ideen, wie man das am besten macht?
Gernot: Ja, eine Beobachtung, die ich selber, vielleicht auch ein bisschen leidvoll, gemacht habe, ist, dass ein Management – also jetzt ganz neutral gesprochen – dass ein Management, was uns nicht beauftragt hat, so ein Review durchzuführen, wenig Spaß daran hat, in einer großen Abschlussrunde, wo alle Beteiligten irgendwie zusammenkommen, massiv überrascht zu werden. Also ich glaube die Leute sind wirklich, die möchten gerne überrascht werden im sonntäglichen Tatort aber nicht in der Abschlusspräsentation. Und was wir jetzt öfter schon ganz erfolgreich oder zur Zufriedenheit unserer Mandanten gemacht haben, ist, dass wir so eine Art Mini-Abschlusspräsentation, das nennen wir dann vorab Ergebnispräsentation, in einer etwas kleineren Runde machen. Also die eigentlichen Auftraggeberinnen oder Auftraggeber mit vielleicht noch 1–2 Leute aus dem Entwicklungsteam. Also so eine kleinere Runde. Und wir als Reviewer, wir zeigen dort schonmal vorab Ergebnisse und sagen: So, wir haben jetzt hier in den Code geguckt ein bisschen, haben was gefunden. Wir haben hier an den Stellen gesucht. Erstens mal, um die Leute vor ganz schlimmen Überraschungen zu schützen. Also, dass sie einfach schonmal, beispielsweise zu Prozessproblemen, da tritt das halt ganz eklatant zu Tage. Dass man sagt: So, ihr habt hier einen Entwicklungsprozess, vom Fachbereich kommen Anforderungen über diesen und jenen Weg zum Team und da gibt es halt folgendes Problem. Sowas möchte ich mit den Leuten vorab diskutieren, damit sie auch zu sowas Stellung nehmen können. Uns ist auch schon vorgekommen, dass wir vermeintliche Defizite in einem Testprozess gefunden haben und in einem Vorabgespräch dann rauskam: Ah, das muss so sein, weil es noch ein Nachbarsystem oder eine Nachbarabteilung gibt, die das so brauchen. Das heißt wir konnten da gar nichts dran machen, das war auch kein Potential, das man irgendwie verbessern oder erheben konnte. Und dann war es einfach gut, dass wir im Vorabgespräch das schonmal klären konnten. Auf der anderen Seite haben wir im Vorabgespräch so Indikatoren gezeigt und gesagt: Mensch, wir glauben, dass da an dieser Stelle das wirklich ein großes Problem ist und das Management dann gesagt hat: Da müsst ihr aber nochmal genauer reingucken, das sieht ja wirklich interessant und spannend aus! Und dann wurde wirklich im Vorabgespräch quasi unsere Review-Richtung ein bisschen justiert. Das ist ja beim iterativen Arbeiten so. Und im dem Sinne dient dieses Vorabgespräch ja sozusagen der Iterationssteuerung des eigentlichen Reviews. Also dass man da eine Chance gibt, also auch den betroffenen Personen gibt, eben dazu Stellung zu nehmen oder zu sagen: Mensch, das glauben wir nicht. Da müsst ihr nochmal nachgucken. Und das hat sich bei uns als eine gute Praxis, als so ein ‚will ich nicht mehr missen‘ Aspekt rausgestellt.
Lucas: Ja. Und aber das Gespräch klingt jetzt auch ein bisschen so als würdest du da mehr mit Gesprächen/Präsentationen arbeiten und nicht so sehr mit schriftlichen Ausarbeitungen. Höre ich das richig?
Gernot: Also ich stehe an der Stelle wirklich auf Präsentieren. Also wir als Review-Team, wir präsentieren in der Vorabpräsentation halt Vorabergebnisse, die gibt es auch schon schriftlich. Also die sind schon auch in, meinetwegen jetzt PowerPoint oder sowas, sodass die Leute auch mal etwas nachgucken können, aber nicht schriftlich im Sinne von wir haben da schon so ein halbfertiges Buch geschrieben. Ich mag an der Stelle lieber eine dicke Sammlung von Folien. Auch auf Folien kann ich ordentlich Text schreiben in die Notizen oder in Backup Folien. Und ich würde lieber dieses Medium der, also das interaktive Medium der Präsentation nutzen, damit man über die Dinge halt auch reden kann, als so einen wirklich geschliffen formulierten Report über den Zaun zu werfen. Also da ist mir die Interaktion wichtiger, also gerade auch was Priorisierung und so weiter angeht. Da können wir halt als Reviewer gute Vorschläge machen. Aber: Also ich bin ja immer externer Reviewer gewesen und ich habe natürlich immer nur so eine Momentaufnahme eines Unternehmens. Das heißt ich habe ja nicht immer die Weisheit mit Löffeln gefressen. Und das kommt auch glaube ich bei so Review Projekten ganz gut an, wenn man sagt: So, wir möchten auch die Ergebnisse vorstellen, möchten gerne da mit euch drüber reden und ihr kriegt halt unsere PowerPoint Präsentation gerne in Schriftform. Und die ist auch ausführlich, also nicht nur fünf Schlagworte drauf. Aber das ist mir wichtiger als ein, wie gesagt, geschliffen formulierter Report, zu dem es dann keine Interaktion gibt.
Lucas: Ja. Was mich jetzt zum Abschluss noch interessieren würde ist so: Was ist denn dein persönliches Interesse an Reviews? Warum findest du das was Interessantes, etwas was dich immer wieder reizt?
Gernot: Der Lucas stellt mir dann so schöne Fragen in… Nein Spaß! Ich durfte halt ein paar Reviews in meinem Berufsleben durchführen und ich mag unseren Beruf ohnehin, weil man da dauernd was lernt. Aber der Lernfaktor in Reviews ist der für mich mit Abstand höchste, den ich hatte, weil ich… Ich habe halt Situationen gesehen, wo ich sag: Ich verstehe es nicht. Aber das Entwicklungsteam konnte es mir erklären und dann habe ich gesagt: Wow! So kann man das Problem auch lösen. Weil ich halt meine Meinung habe, wie ich halt Dinge entwickeln würde oder wie ich sie von der Architektur her gestallten würde und ich habe da echt viel bei Reviews gelernt, wie einfach andere Teams Dinge anders machen. Also ich habe Jahre meines Lebens in Entwicklungsteams verbracht, um konstruktiv selber Systeme zu entwerfen, aber da kenne ich natürlich nur das, was wir gemacht haben. Das habe ich zwar dann sehr gründlich kennen gelernt, weil ich es auch selber gemacht oder mitgemacht habe, aber in Reviews kann ich dann halt eben auch mal andere Dinge auch kennenlernen. Also dieser Lerneffekt, dass ist das was mich extrem reizt. Und dann kann ich halt ein Team, das Dinge gemacht hat, meine Erfahrung auch spiegeln. Also ich merke halt auch, dass das so ein Team, das ich reviewe oder wo ich etwas reviewe, dann auch freut und von mir dann mal hören kann, wie könnte man es dann eben vielleicht anders machen. Sehr, sehr schönes und sehr, sehr fruchtbares Betätigungsfeld.
Lucas: Ja. Was ich da auch raus höre, was mir auch total wichtig ist, ist auch, mit der Einstellung reinzugehen, dass vielleicht Sachen anders gelöst sind, als man es selber machen würde, was aber nicht unbedingt falsch ist.
Gernot: Genau!
Lucas: Das ist glaube ich eine ganz wichtige Einstellungssache, mit der man da reingehen sollte.
Gernot: Also ich kann mich an ein Review erinnern, wo wir wirklich technisch extrem wenige Dinge gefunden haben. Und es war ganz lustig, wir haben halt zwei Wochen/drei Wochen relativ viel Zeit in diesem Unternehmen verbracht. Also auch mit den Entwicklern, Entwicklungsteams da gemeinsam Mittag gegessen, in der Kaffeeküche gestanden und wir haben so viel meckern gehört von Leuten, die intern über ihr eigenes System meckern. Und in der Abschlusspräsentation oder auch schon in der Vorabpräsentation haben wir gesagt: Leute, wir haben den Eindruck, ihr wisst gar nicht, wie gut euer System eigentlich gebaut ist. Wir haben dann mal so ganz grob, also natürlich unter Einhaltung aller NDAs, aber so ganz grob mal gezeigt, wie halt andere Unternehmen dieses Problem lösen und unter welchen Schwierigkeiten andere leiden. Und dann, ich erinnere mich an eine Entwicklerin, die gesagt hat: Das ist ja das erste Mal seit Ewigkeiten, dass uns einer lobt, was wir da machen. Weil das war dem Team überhaupt gar nicht klar, wie gut sie manche Dinge gemacht haben. Ja, auch sowas kommt im Review vor. Es gibt nicht immer nur Bashing, Meckern über irgendwas, sondern es ist halt wirklich so, dass man Dinge findet, wo man sagt: Wow, das ist aber extrem gut gemacht! Ja, das ist ein spannendes Thema.
Lucas: Ja, das finde ich einen tollen positiven Abschluss. Für die Hörerinnen und Hörer, die vielleicht noch mehr erfahren wollen, hast du glaube ich mit ein paar Kolleginnen und Kollegen einen Primer geschrieben. Magst du dazu noch ein, zwei Worte sagen?
Gernot: Ja, gerne. Also vielleicht müssen wir kurz erläutern was ist ein Primer. Ein Primer ist ein kleines Büchlein, was in eine Thematik einführt und einige Primer, die ich so gesehen habe, sind so 20–30 Seiten Büchlein. Das haben wir schlicht nicht geschafft, also weil alleine das Thema Breitensuche, das wir ja ein bisschen ansprechen wollten, wo wir einige Pflöcke einschlagen wollten: es sind so ungefähr achtzig Seiten geworden, die wir als E-Book rausgegeben haben. Wir packen mal einen Link in die Shownotes dazu. Wir haben den auf Deutsch geschrieben. Den gibt es mittlerweile auch auf Englisch, die russische Übersetzung ist gerade in Mache. Wo wir vieles von dem was wir jetzt im Podcast hier angesprochen haben noch etwas detaillierter darstellen und insbesondere eben auch die sehr kundigen und erfahrenen Kolleginnen und Kollegen da noch ihre Meinung mit reingepackt haben.
Lucas: Super! Gut Gernot, dann danke ich dir für das tolle Gespräch!
Gernot: Lucas, vielen Dank für dein Interesse und allen noch ganz, ganz vielen Dank fürs Zuhören und Interesse am Thema!
Lucas: Genau und dann sage ich den Hörerinnen und Hörern bis zum nächsten Mal! Tschüß!