Qualität in der Softwareentwicklung.

Herzlich willkommen zur Premieren-Folge vom Webcafé.

Das ist unser regelmäßiger Podcast zum Thema Web-basierte Softwareentwicklung und Unternehmenskultur. Und eure Hosts sind heute der Kay, seines Zeichens Technical Lead bei der GnRT-Systeme GmbH aus Dortmund.

Und ich bin Felix, Gründer und Geschäftsführer, genau da auch bei der GnRT-Systeme GmbH. Und Kay, ich habe heute Morgen gelesen, wie der Elon Musk sich seit Neuestem nennt bei Tesla.

Hast du das auch gelesen? Ich habe es noch nicht gelesen, ne. Ja, er sagt, er ist der Techno-King of Tesla. Und weshalb ich darauf komme, ist, weil wir uns ja immer ein bisschen schwer tun, für dich eine Positionsbezeichnung zu finden. Jetzt haben wir Technical Lead hier drauf geschrieben. Ich glaube, da kann sich jeder so ein bisschen was darunter vorstellen. Ich muss es auch jedes Mal erklären, wenn ich mich irgendwo vorstelle. Und dann sagen die, aha, Technical Lead, das klingt dann ganz großartig. Aber was steckt denn dahinter? Und da komme ich dann auch ins Straucheln. Ja, das Wichtigste ist natürlich, dass es Englisch ist.

Genau. Genau. Ja, grundsätzlich beschäftigen wir uns beruflich und privat mit webbasierter Softwareentwicklung und auch Unternehmensführung. Und da wollen wir euch in diesem Podcast einfach mitnehmen und die Themen, die uns im Alltag begegnen, einfach ein bisschen näher bringen. Ich bin ganz gespannt. Für heute habe ich zwei Dinge mitgebracht. Nämlich einerseits, das gehört dazu für mich, einen schönen Schwarztee. Den habe ich in Stockholm kennengelernt. Und zwar über eine schwedische Freundin, die wir da besucht haben. Und ja, ganz hervorragender Tee, den ich mir jetzt mit einem Stück Kandes und ein bisschen Hafermilch verfeinert habe.

Und das ölt hier hoffentlich meine Stimme für die erste Folge, damit das flüssig runtergeht. Jetzt kommst du so direkt perfekt vorbereitet und meinen Tee habe ich hier gerade leer getrunken, weil er schon dran und drauf war, kalt zu werden.

Und ich mache jetzt aber keinen neuen, da muss ich jetzt mit Wasser durch. Und was ist das Zweite? Ohne Tee und Kaffee geht es natürlich nur halt gut. Ja, das Zweite ist natürlich unser Thema. Und das ist heute ein dicker Brocken, den wir uns zum Start ausgesucht haben. Und zwar ist das die Qualität in der Softwareentwicklung. Und das haben wir mitgebracht, weil das einfach auch bei uns in der Firma ein ganz großes, wenn nicht sogar zentrales Thema ist. Und dann haben wir gedacht, das ist vielleicht das Richtige, um hier im Podcast auch einen Einstieg zu bekommen und wirklich erstmal so ein großes Metathema aufzumachen.

Ich finde, das ist eine sehr gute Wahl für die erste Folge. Und du hast es schon gesagt, wir schreiben uns das ganz oben auf die Fahne und auf die hoffentlich bald neue Webseite. Und es ist natürlich eine Sache, das von sich zu behaupten. Das tun, glaube ich, die allermeisten, die so in der Branche unterwegs sind. Aber ich finde es ganz spannend, mal darüber zu reden, was das denn eigentlich konkret bedeutet. Weil zum einen für die Kunden, aber auch zum Beispiel für die anderen Kollegen ist es ja wichtig zu wissen, was hinter diesem Wort Qualität überhaupt steckt,

damit man sich in der alltäglichen Arbeit so ein bisschen danach richten kann. Ja, Felix, was verstehst du denn darunter? Ja, es gibt ja zuvorderst mal so ein paar Punkte, die jeder direkt mit Qualität, vor allem in der Softwareentwicklung assoziiert. Ich denke, allen voran ist das überhaupt erstmal, dass der Code an sich eine gute Qualität hat und dass wir am Ende eine funktionierende, zuverlässige, robuste Anwendung hinten rausbekommen.

Das steht, glaube ich, so ein bisschen über allem. Aber spannend sind natürlich auch die Punkte, die dann hinten dran kommen. Da habe ich jetzt als nächsten Punkt mir mal notiert, zum Beispiel die Zufriedenheit des Auftraggebers. Gleichzeitig aber auch die Zufriedenheit des Anwenders dann. Und da fallen dann so Punkte rein, wie für den Auftraggeber natürlich, dass zum Beispiel Budget und Termine eingehalten wurden. Oder für den Anwender, dass wir eine intuitive, moderne UI haben, die performant ist, die barrierefrei ist und so weiter. Finde ich ganz gute Punkte, weil bei Qualität ist ja für mich entscheidend, was merkt denn der Kunde davon?

Weil, wie gesagt, draufschreiben kann sich das jeder. Aber wenn er dann eben anhand der Software merkt und vielleicht über das User-Feedback, dass das, was wir da bauen, auch Spaß in der Benutzung macht und vor allem das Problem löst, für die sie gebaut wurde, dann ist das, glaube ich, mit ein großer Schritt hin zu diesem Qualitätsverständnis.

Und nicht nur softwarebezogen finde ich solche Qualitätsansprüche wichtig, sondern generell, wenn es um die Kommunikation mit dem Kunden geht.

Das ist ja letzten Endes derjenige, der uns das Geld gibt für das, was wir hier tun. Und dementsprechend sollte der das hoffentlich auch bemerken, dass wir Qualität liefern. Und dazu eben nicht nur Software, sondern auch, wie treten wir denn als Firma gegenüber dem Kunden auf?

Und ich denke da zum Beispiel an so Sachen wie, dass man einfach in der Kommunikation vernünftig ist und nett und höflich. Das macht gleich einen viel besseren Eindruck. Ja, genau. Also professionelles Auftreten beim Kunden finde ich super wichtig. Du hast jetzt schon gesagt, dass man in der Kommunikation klar ist. Also das kann natürlich schriftlich, aber auch mündlich sein. Ich würde zum Beispiel nie eine Anrede und eine Verabschiedung in der E-Mail weglassen. Einfach, weil ich denke, das gehört so ein bisschen dazu. Dazu gehört aber auch, dass man einfach professionell den Kunden auch beraten kann und das Know-how, was man hat, auch weitergibt.

Und Kay, du hast sicherlich noch weitere Punkte. Ich habe jetzt mal schon noch einen aufgeschrieben, Thema Sicherheit. Würde ich vielleicht noch zum Thema Kommunikation mit dem Kunden sagen, dass da auch sowas zugehört, wie, dass wir die Projektplanung insgesamt transparent um Namen Kunden machen.

Das heißt zum Beispiel bei uns konkret, der Kunde, wenn er möchte, kriegt Zugriff auf unser Projektmanagement-Tool und kann dann direkt da Aufträge einstellen und die Kommunikation mit dem Entwickler führen und auch Zeiterfassung und sowas nachvollziehen.

Ich finde, das ist auch ein Zeichen von Qualität, wenn man eben die ganzen internen Abläufe, allem voran die Zeiterfassung, auch transparent an den Kunden weiterspiegelt zu jeder Zeit, sodass da nicht irgendwie am Ende des Monats erst der große Schreck auf der Abrechnung kommt,

sondern der, wenn er möchte, Tag für Tag sehen kann, was wird gerade gemacht, wo passieren die Zeiten drauf und dann eben auch schnell eingreifen kann.

Ja, ist mir auch super wichtig und ich erzähle auch immer allen Kunden, hier könnt ihr mich jeden Tag fragen, wie viele Zeiten wir getrackt haben, wo wir stehen und ich werde es immer live und verfügbar haben und da eben sehr transparent sein, wenn nicht der Kunde direkt einen Zugriff hat und auch direkt reingucken kann.

Finde ich super spannend. Und das sind ja gerade auch so Punkte, die man nicht unbedingt immer auf dem Schirm hat, wenn man über so Qualität redet, weil das ist ja dann häufig sehr sachbezogen und letzten Endes geht es natürlich auch um tolle Software, die wir bauen.

Aber dieses Ganze drumherum, das ist auch ein sehr wichtiger Bestandteil für den Rahmen und, glaube ich, großer Einfluss auf das Qualitätsverhältnis gegenüber dem Kunden, weil, dass wir intern gute Software schreiben, gut und schön, aber an solchen Eckpunkten merkt er eben, dass da wirklich was hinter steckt.

Ja, genau. Das ist ein Thema, das dir immer super wichtig ist, dass der Kunde eben auch merkt, dass wir gute Qualität machen. Ich lege vor allem eben auch den Fokus darauf, dass die gute Qualität da ist und versuche das dann zu erzählen.

Aber da muss man natürlich Kunden haben, die einem das auch glauben und viel besser ist natürlich, wenn der Kunde das wirklich merkt, indem man zum Beispiel eine Anwendung dann rausbringt, die merklich performant ist oder die vielleicht eine Vorgängeranwendung einfach in den Schatten stellt, dadurch, dass sie deutlich innovativer ist, deutlich besser funktioniert, besser aussieht, modern wirkt.

Das sind natürlich alles Punkte, mit denen man dem Kunden, glaube ich, das schon zeigen kann, dass man eine gute Qualität entwickelt, ohne dass man darüber sprechen muss. Jetzt können wir vielleicht langsam mal konkret Richtung die Implementierung und die Software gehen, dann kannst du nochmal deinen Sicherheitspunkt ansprechen. Genau. Ich würde tatsächlich noch einmal einschieben, wie wir da überhaupt hingekommen sind, dass wir so einen Fokus auf Qualität haben bei uns, weil ich so das Gefühl habe, dass es ganz viele Firmen da draußen gibt, vielleicht muss ich es umdrehen,

Es gibt ganz viele Firmen, die tolle Software entwickeln, die super Qualität machen. Es gibt sicherlich auch zig Firmen, die bessere Software entwickeln als wir. Natürlich sind wir selbst auch noch auf dem Weg und nichtsdestotrotz gibt es aber auch ganz viele Softwareprojekte, die mit mittelmeistiger Qualität geschrieben sind und da kommt, glaube ich, jeder so ein bisschen her, dass man früher, können wir uns daran erinnern, mit FTP-Dateien direkt bearbeitet hat, also auf dem FTP-Server direkt bearbeitet hat, dass man keine Versionierung hat,

dass man eben als einzelner Entwickler an den Projekten wirklich gefummelt hat und dann macht man natürlich so einen Prozess mit.

Und ich glaube, in dem Moment, wo man alleine entwickelt, ist das alles gar nicht so ein großes Problem. Meistens hat man einen ganz guten Überblick über die ganze Anwendung und kann sich auch grob vorstellen, wenn ich irgendwas ändere im Code, dass es vielleicht an einer anderen Stelle auseinanderfliegen könnte.

Aber spätestens dann, wenn man in einem größeren Team arbeitet und Mitarbeiter dazukommen, dann merkt man ziemlich schnell so, da müssen wir jetzt Maßnahmen ergreifen, dass uns nicht jede Woche an irgendeiner Ecke was anderes auseinanderfliegt.

Und ich finde, mit besserer Qualität in der Software können auch gleichzeitig die Softwareprojekte wachsen, weil du hast schon recht, diese FTP-Uploads einfach auf irgendeinen WordPress-Server drauf, das hat schon auch seinen ganz eigenen Charme.

Aber abgesehen davon, dass man da natürlich nicht so die Coding-Guidelines und Prinzipien anlegen kann, die wir jetzt heute haben, ist man natürlich auch nicht davor geschützt, dass man mal einen Syntax-Fehler einbaut, so einen Semikolon vergisst und dann stürzt halt die Live-Seite vom Kunden ab.

Das kann man halt bei so kleinen Seiten mal machen, aber bei größeren Seiten wird das dann gleich mit sehr viel dramatischeren Ausmaßen belohnt, will ich mal sagen.

Und wenn man dann es schafft, Qualität in seine Software reinzubringen, heißt es auch in meinen Augen automatisch, dass man auch größere und wichtigere Projekte stemmen kann.

Ja, absolut. Und mit unseren ersten größeren Projekten kamen ja dann eben auch die Probleme und dann hatten wir zum Teil wirklich Phasen, wo wir, ich sag mal jetzt in Anführungsstrichen, in Angst gelebt haben, dass ein Kunde anruft, weil ein Fehler aufgetreten ist.

Oder wenn wir einen Release gemacht haben, dass wir dann wirklich die nächste Stunde geschwitzt haben, dass alles glatt geht und dann die Anwendung per Hand getestet haben und geguckt haben, läuft da noch alles.

Und vielleicht hat dann am nächsten Morgen doch jemand angerufen und hat gesagt, oh, hier in einem Online-Shop klappt aber was nicht mehr. Und das war natürlich ein Zustand, wo wir dann wussten, da müssen wir eigentlich was dran ändern. Ich glaube, dass wir dann vor allem den Dreh da reingekriegt haben, indem wir uns auch ein Coaching dazu geholt haben mit jemandem, der sehr, sehr viel Erfahrung hatte.

So in den Bereichen Softwarequalität, Softwareentwicklung, aber auch so Stichworten wie CICD, also Pipelines, Continuous Integration, Continuous Deployment.

Und das war für uns, denke ich, so ein Meilenstein, um dann Richtung wirklich Softwarequalität auch zu gehen. Ich denke auch, also das ist der große Punkt, den ich aus dieser ganzen Geschichte mitnehme, warum diese Qualität wichtig ist. Und das ist bei mir persönlich einfach diese Entlastung auf der Seele, wenn man halbwegs sicher sagen kann, dass den Release-Button, den man da jetzt gerade drückt, nicht dafür sorgt, dass die ganze Webseite kaputt geht, weil man irgendwas übersehen hat.

Und wie du gesagt hast, dieser externe Impuls, den wir da bekommen haben, von außen mal gezeigt zu bekommen, wie andere das denn vielleicht machen, das ist auch in meinen Augen, glaube ich, der größte Schritt, den wir da gemacht haben.

Also um vielleicht jetzt schon mal ein Fazit wegzunehmen. Ich glaube, alleine, wenn man sich schon mit den Themen beschäftigt, hat man schon einen großen Schritt gemacht hin zu tatsächlich diese Qualitätsziele auch zu erreichen.

Definitiv, genau. Ja, du wolltest vorher darauf einsteigen, wie wir dann konkret die Qualität sichern und den Ball würde ich jetzt gerne nochmal aufnehmen.

Wir haben eventuell schon über Versionierung gesprochen. Ich kann mich nicht ganz genau daran erinnern, aber das ist für mich der allererste Punkt.

Gar nicht unbedingt der wichtigste, aber ich würde sagen, ohne Versionierung geht gar nichts. Ja. Und ich denke, da ist Git im Moment schon das Tool der Wahl. Ich weiß nicht, ob du mal mit anderen gearbeitet hast. Das ist jedenfalls das, was wir einsetzen und das funktioniert einfach super gut und ist die Basis wirklich für alle weiteren Maßnahmen, die wir machen. Also von Reviews bis Testing und Pipelines, das basiert alles irgendwo im weitesten Sinne dann auch auf der Versionierung auf Git.

Genau. Ich glaube, wir brauchen jetzt zu jedem Stichpunkt, den wir jetzt anschließend nennen werden, nicht darauf einzugehen, was das konkret bedeutet.

Da würden wir dann wahrscheinlich eher Folgepodcasts machen, weil zu jedem einzelnen Punkt, alleine Versionierung, kann man, glaube ich, ganze Vorträge füllen.

Aber ich stimme dir zu, dass die Versionierung auf jeden Fall für die handwerklichen Sachen, die wir gemacht haben, die wichtigste Grundlage ist.

Genau. Und für mich ist dann der nächste Punkt, und den würden sicherlich die allermeisten auch als wichtigsten Punkt dann benennen, dass wir wirklich sauberen Code versuchen zu schreiben. Stichwort ist da Clean Code. Da haben wir jetzt verschiedene Maßnahmen implementiert, um sicherzustellen, dass wir eben guten Code haben. Weil man kann natürlich sagen, man macht jetzt guten Code, man macht modernen Code. Aber am Ende ist ja das Interessante, wie stellen wir das sicher, dass das auch nicht nur eine Floskel ist, sondern dass tatsächlich auch guter Code dann produziert wird und ausschließlich guter Code auch in den Hauptbranch,

in den Mainbranch dann eingefügt wird und am Ende live geht. Sehr gut, genau. Der erste Punkt, das ist, glaube ich, der naheliegendste, sind einfach automatisierte Tests. Also Unit-Tests, Feature-Tests, da gibt es ja zig verschiedene Bezeichnungen. Und das bedeutet, automatisiert Testschreiben, die bestimmte Aspekte der Software testen können.

Also sicherstellen, dass die jetzt gerade funktionieren und vor allem aber auch sicherstellen, dass die in Zukunft noch funktionieren. Genau, und ich denke, allen voran müssen wir da schon die Unit-Tests dann auch nennen, die man unserer Empfehlung nach schon durchgehend auch machen sollte und da eigentlich auch nicht ein Auge zudrücken darf an bestimmten Stellen,

sondern Unit-Tests müssen da sein und die Anwendung muss in der kleinsten Einheit mindestens mal getestet sein.

Und wenn man dann auf eine höhere Ebene geht, funktional Tests und so weiter, End-to-End-Tests, dann muss man sich überlegen, so was ist jetzt sinnvoll für meine Anwendung? Aber ich denke, auf Ebene Unit-Tests müssen wir da eigentlich kompromisslos unterwegs sein. Da machen wir sicher nochmal einen separaten Podcast darüber, was wir testen, welche Gesichtspunkte, welche Konzepte, welche Formate wir da benutzen und sowas. Das wird jetzt hier den Namen sprengen. Deswegen schwinde ich mal weiter zum nächsten. Und neben Testen ist auch, finde ich, die einheitliche Code-Qualität wichtig. Stichwort Linting.

Das bedeutet eben, darauf aufzupassen, dass insbesondere mit mehreren Entwicklern der Code einheitlich ist. So was wie Semikolon-Sätzen, wo passieren die Umbrüche und so weiter. Das ist augenscheinlich erstmal ein kleiner Aspekt, weil er eben keinen direkten Einfluss auf die Software hat. Die funktioniert auch so oder so. Aber für die ganze Einarbeitung und die Wiederfindbarkeit und die Orientierung im Code, finde ich das sehr wichtig. Genau, erhöht auch die Wartbarkeit. Und man kann bei uns wirklich sagen, über unsere Projekte, projektübergreifend, wenn man sich einen Code anguckt, dann erkennt man den Code einfach wieder.

Und dann sieht man, ah, das ist eine Struktur, die ich schon mal gesehen habe. Das ist eben super wichtig. Und das Allerwichtigste am Linting, finde ich eigentlich, dass das eben nichts ist, was hinterher in den Reviews noch aufpoppt. Reviews ist ein Punkt, auf den ich dann gerne als nächstes auch eingehen würde. Sondern das sind eben Dinge, die sind eigentlich so banal und so einfach, dass wir die automatisiert abfrühstücken wollen. Und keiner soll aus seinem Editor überhaupt irgendwas rauskriegen, was nicht unserer Struktur entspricht, also was nicht gelintet ist.

Und genauso haben wir dann später in den Pipelines auch Schritte drin, die sicherstellen, dass nichts in unsere Branches reinkommen kann, was nicht diesem Linting entspricht.

Und das ist ganz essentiell. Das soll keiner manuell irgendwie rausfinden, ah, da fehlt eine Klammer oder so. Oder hier, das schreiben wir mit einer Arrow-Funktion anstatt anders. Sondern das soll wirklich automatisiert passieren. Und da soll keiner manuelle Mühe mithaben, weder ein Entwickler noch hinter jemand, der dann drüber guckt. Genau, du hast das gerade so im Beisatz erwähnt, aber das ist eigentlich ein entscheidender Punkt. Leute, also Entwicklerinnen und entwickelnde Menschen generell, können auch problemlos mal Projekte wechseln und in andere Projekte rein, wenn sie den Tech-Stack können.

Weil sie eben durch das einheitliche Linting auch sich relativ schnell in fremden Projekten zurechtfinden können, weil der Code genauso aussieht wie in anderen.

Zusammen mit gescheiten Ordnerstrukturen, das ist der nächste große Punkt, also generell eine saubere Software-Architektur, die trägt auch dazu bei, dass sich Leute schnell wiederfinden können.

Und dazu zählt zum Beispiel, wie man Dinge benennt, wie man Dinge strukturiert, wie man Verzeichnisse aufbaut und so weiter. Auch nochmal ein komplett eigener Punkt für sich und sicherlich in deinem eigenen Podcast-Wert. Aber das zählt da auch so rein, großes Thema Struktur in der Software. Genau, und Architektur ist so einer der Themen, wo ich jetzt sagen würde, das kann man nicht mal eben so reinwerfen und dann kann das jemand übernehmen.

So eine Architektur entsteht natürlich ganz viel auch aus einer Erfahrung von Entwicklern. Und da ist bei uns auch ein großes Thema, dass wir eben erfahrene Entwickler mit in die Konzeptionsphasen reinsetzen und natürlich hinterher den Reviews auch drin haben.

Weil ich denke, dass ein Junior-Entwickler sich einfach etwas schwerer damit tut, von Anfang an einen Programmmodul zu überblicken und eine gute Struktur sich zu überlegen.

Da hilft dann wirklich die Erfahrung von jemandem, der größere Projekte schon umgesetzt hat, der einfach schon viel entwickelt hat. Und genau, das ist ein essentieller Faktor bei uns, dass man schon auch erfahrene Entwickler da mit drin haben muss. Genau, du hast es gerade schon angesprochen. Das stellt man natürlich über Code-Reviews sicher. Das steckt in dem Wort Versionierung ja so ein bisschen drin. Also jeder Code, der auf den Mainbranch soll, muss vorher gereviewt werden. Und da zählen natürlich zum einen diese ganzen Dinge zu, die wir gerade genannt haben. Also die Tests müssen still im Linting.

Zum Thema Pipeline würde ich gleich nochmal separat was sagen. Aber dann eben auch, wie du es gerade schon gesagt hast, Felix, der handliche, händliche, also der Test von Hand von erfahrenen Entwicklern, die eben auf so Sachen draufschauen, die ein Linter nicht unbedingt kann.

Also Code-Struktur, Abhängigkeiten zu anderen Bausteinen und so weiter. Da kommt ja ganz viel rein. Und nur durch intensive Code-Reviews kann man sicherstellen oder sichererstellen, dass eben solche größeren Zusammenhänge auch passen, die man vielleicht durch Tests oder so nicht so gut abbilden kann.

Und ich kann aus früheren Projekten sagen, in denen ich gearbeitet habe, auch in größeren Firmen, dass oft Reviews gemacht wurden. Also dass ein Code, der vermeintlich fertig ist, eben einem anderen Entwickler dann auch zur Sichtung gegeben wird. Und in anderen Firmen habe ich es immer so festgestellt, dass ein Review eigentlich so ein Durchscrollen ist. Also man nimmt sich dann irgendwie in GitLab oder so den PR oder Merge Request, wie auch immer man den nennen will. Und dann scrollt man so durch und dann fällt einem auf so, ah, hier ist aber was, was mir jetzt komisch vorkommt. Dann schreibe ich mal einen Kommentar rein.

Und das ist schon was, was wir ein bisschen anders angehen bei uns und was ich wirklich auch jedem mitgeben kann und empfehlen kann. Das ist wirklich absolut zentral bei uns, dass wir uns in den Reviews wirklich in den Code eindenken, versuchen zu verstehen, was da passiert. Und genau diese architekturellen Dinge auch dann da rausziehen und bemerken, weil die einfachen Sachen eben normalerweise so ein Linter oder sowas machen soll.

Das heißt wirklich dieses intensive Beschäftigen mit dem Code, das kostet natürlich Zeit. Das erzeugt auch ein Overhead am Ende. Aber ich glaube, dass wir damit so viele Fehler und Stolperfallen rausziehen, die uns später sonst wieder begegnen würden, dass sich das wirklich lohnt, da auch die Zeit zu investieren.

Ja, und wir benutzen das auch gleichzeitig als Fortbildung für die Leute. Das heißt, wenn man dann im PR feststellt, dass da irgendwie konzeptionell was nicht ganz stimmt, dann nimmt man sich halt die Zeit, holt sich die Leute dabei und erklärt dann auch die Konzepte mündlich.

So Zwischentür und Angel, sag ich mal, man ruft die einfach an und sagt dann, hey, schau mal hier, ich habe gesehen, du hast das und das gemacht. Wusstest du vielleicht, wie die Zusammenhänge sind? Schau mal hier, gibt es noch das und das und jenes? Statt einfach nur im Review anzumerken, hier, mach das mal anders. Dann die Chance nutzen und das so als Lerneinheit wirklich zu benutzen. Aber wie du sagst, das ist natürlich unfassbar aufwendig und damals auch kostenintensiv und zeitintensiv. Genau, ich denke, zu Thema Review können wir auch wieder einen eigenen Podcast machen. Aber vielleicht noch zwei Punkte zum Abschluss.

Das Erste ist, dass wir natürlich versuchen, in den Reviews immer sehr, sehr positiv zu sein. Also wir wollen ja jetzt nicht irgendwie Fingerpointing machen und jemandem sagen, guck mal, da hast du Fehler gemacht. Sondern ganz im Gegenteil, wir wollen mit den Leuten einfach eine bessere Codequalität erarbeiten und sehr, sehr positiv dabei sein. Und ich kann jetzt von unseren Entwicklern und Entwicklerinnen sagen, dass sie das eigentlich alle super positiv aufnehmen und alle einen, das wäre der zweite Punkt, einen richtig guten Weg nehmen.

Beim ersten Review hat man vielleicht 10, 15, 20 Kommentare drin, über die man dann alle im Einzelnen spricht. Und dann dauert so ein Review auch mal einen ganzen Tag. Und nach einem halben Jahr oder einem Jahr merkt man dann, dass man kaum noch was anzumerken hat an einem Code. Und die Leute wirklich eine super steile Lernkurve haben und einen richtig guten Weg gegangen sind und einfach auch viel bessere Entwickler werden.

Ich finde, was bei Versionierung und Code Reviews auch mal so ein bisschen mitschwingt, ist das Thema Pipelines. Und das bedeutet, ja ganz grob gesagt, dass man die einzelnen Bausteine, die wir vorhin genannt haben, wie zum Beispiel Tests oder Linting, auch schon automatisiert feststellen kann.

Das bedeutet, wenn jemand ein Code Review macht, läuft da eine Pipeline drüber und die prüft direkt, ob Tests und Lints und so weiter funktioniert.

Die kann dann noch weitere Sachen machen. Das wird jetzt auch wieder hier den Rahmen zusprengen, alles aufzuzählen. Aber was ich an dem Thema Pipeline und so Automatisierung das Entscheidendste finde, ist, dass durch diese automatisierten Prozesse, die an solchen Schritten, die den Code verändern, dranhängen, dass die nicht optional sind.

Das bedeutet, man kann nicht Code committen und auf den Masterbranchen, wenn nicht diese automatischen Prozesse wie Linting und Tests abgeschlossen sind.

Und das zwingt die Leute dazu, das zwingt uns als Firma dazu, diese Qualitätsmechanismen, die wir uns auferlegt haben, wie zum Beispiel die Tests, jedes Mal auszuführen.

Die zwingt uns dazu, die wahrzunehmen, weil es nicht anders geht. Wenn es sonst um irgendwelche Qualitätsversprechen geht, sag ich mal, und die sind optional und irgendwie ein manueller Schritt, dann passiert das häufig, dass das hinten rausfällt.

Aber durch diesen Zwang, durch die Automatisierung, dass man immer linden muss, dass man immer testen muss und so weiter, hat man diesen ganzen Qualitätsanspruch intrinsisch, das ist mein Lieblingswort, abgebildet.

Definitiv. Bei den ganzen Pipeline-Geschichten, das ist ja für viele auch so ein bisschen so eine Blackbox und auch wieder ein eigenes Thema.

Aber worauf ich eingehen will, ist, dass da ganz wichtig ist, dass sie einfach auch sehr, sehr gut funktioniert und sauber durchläuft und nicht irgendwie ein Fehler entsteht, wo man dann jedes Mal sagt, ah, den kannst du ignorieren.

Sowas darf eigentlich nicht auftreten, sondern die Pipeline, die muss einem eigentlich zuarbeiten, die muss einem helfen, die muss sauber laufen, die muss im besten Fall schnell laufen. Wir kennen alle, die Pipelines, die in zwei, drei Stunden dauern. Damit ist eigentlich keinem geholfen und das muss man tunlichst vermeiden. Und da kann ich auch nur jedem ans Herz legen, wirklich jemanden da reinzuholen, der in DevOps wirklich professionell unterwegs ist und sich da auskennt und das vernünftig aufsetzen kann, dass das keinen nervt, sondern wirklich allen hilft.

Hast du jetzt noch weitere Punkte zu dem Thema oder wollen wir langsam zu dem Thema Probleme kommen, die da mit einhergehen?

Ich würde gerne ins Thema mit den Downsides switchen, damit wir nämlich das Thema Dokumentation in der Qualität skippen können.

Das ist ja so eins, woran sich die Geister dann doch sehr scheiden, ob eine Dokumentation jetzt richtig und wichtig ist oder sinnvoll ist.

Ich glaube, das müssen wir vertagen, das Thema. Wir sind jetzt nicht die allergrößten Fans von umfänglichen Dokumentationen, einfach weil wir denken, dass die in dem Moment eigentlich, wo man sie geschrieben hat, auch schon fast wieder veraltet sind.

Und ja, also für mich ist es nicht so ein wahnsinnig gutes Tool, auch wenn man nicht immer drumherum kommt. Jetzt hast du es ja ganz sneaky doch mit reingenommen. Durch die Hintertür. Genau, aber die Probleme nehmen wir gerne mit auf und das Erste vielleicht, was ich mal reinschmeißen kann, ist durch die Reviews kommen natürlich auch dann so Review-Warteschlangen, sage ich mal, Review-Queues auf.

Das heißt, es sind jetzt mehrere PRs, die anstehen, die jemand sichten muss und dadurch verliehe ich natürlich in der Entwicklung schon auch Zeit.

Also ich habe einen Code eigentlich fertig. Ich brauche nochmal jemanden, der drüber guckt und erst, wenn das passiert ist und vielleicht noch ein, zwei Schleifen genommen hat, kann ich den Code dann wirklich veröffentlichen.

Das heißt, ich bin natürlich definitiv so ein bisschen langsamer, auch einfach durch die Zeit, die verloren geht, wenn ich das jemandem anders rüberschiebe, bis der das bearbeitet hat.

Ja, da steckt ein größeres Thema drin, nämlich, dass sich durch diesen auch sehr komplizierten Tech-Stack, den man dann hat, wenn man die ganzen Dinge beherzigt, die wir gerade aufgezählt haben, einfach auch sehr viele Bottlenecks ergeben und bestimmte Rollen und Aufgaben nur von bestimmten Leuten erledigt werden können.

Und sich dementsprechend dann so Hindernisse ergeben wie, naja, der ist jetzt krank, was machen wir jetzt? Die Pipeline ist kaputt, derjenige, der sich mit der Pipeline auskennt, ist gerade nicht da.

Was machst du jetzt? Du musst entweder sehr viel Wissen, das so eigentlich um den Code herum geht, verteilen im Team oder eben irgendwelche Redundanzen schaffen.

Aber es ist auf jeden Fall ein schwieriges Thema, mit so einem breiten Tech-Stack die Leute immer alle auf derselben Höhe zu wissen. Ja, definitiv. Und wir versuchen ja, den Tech-Stack schon auch ein bisschen einzugrenzen, dass jetzt nicht immer alles, was neu und toll ist, mit reingenommen wird, sondern wir sprechen ja immer von abgehangenen Sachen, die wir verwenden.

Und das macht es dann so ein bisschen einfacher, wenn man das ein bisschen einschränkt. Aber nichtsdestotrotz bleibt das natürlich bestehen, dass man immer Experten für bestimmte Themen hat.

Und in dem Moment, wo die nicht greifbar, nicht verfügbar sind, bekommt man ein Problem. Ja, und auch mit Nachwuchs. Früher mit dem FTP- und PHP-Verzeichnis war das alles ganz einfach. Da könntest du jeden Menschen, der PHP kann, da dran setzen. Und je komplizierter der Tech-Stack wird, also jetzt nicht nur mit der eigentlichen Anwendung, sondern auch diese ganzen Meta-Funktionalitäten wie Linting, Testing, Pipelines und so weiter.

Alles noch ein weiterer Schritt, was die Einstiegshürde für neue Leute erhöht. Definitiv. Und du hast jetzt eben schon mal gesprochen von einem Knopf, auf den man drückt, für einen Release. Da haben wir ja so die Themen, dass man zum Beispiel so Bugfixes, gerade so Hotfixes, die also sehr zeitkritisch sind, die schnell eingespielt werden müssen.

Die kommen auch an unserer Pipeline nicht vorbei, in den allermeisten Projekten zumindest. Und dann hat man natürlich auch das Problem, dass man nicht mal eben in zwei Minuten einen Bug fixen kann, sondern das dauert dann schon mal eine Viertelstunde. Da drückt man natürlich dann schon auch ein Auge zu bei einem Review, wenn es dann wirklich sehr kritisch ist. Aber definitiv nicht so schnell, wie wenn ich einfach auf den Server gehen würde und gerade eben was ändern würde. Man hat ja jetzt schon so durchgehört zwischendurch, dass das eigentlich ein ganz schöner Luxusanspruch ist, den wir da haben.

Weil diese ganzen Iterationsschleifen, du hast das gerade angesprochen, natürlich letzten Endes dem Kunden gegenüber in Rechnung gestellt wird.

Und auch wieder, um ein eigenes Podcast-Thema schon mal anzuteasern, ich glaube, den Kunden davon zu überzeugen, eben dass Tests wichtig sind, dass Linting wichtig sind und dass dadurch unterm Strich der Gesamtpreis initial größer wird, da kannst du, glaube ich, ein ganz großes und leidvolles Lied von singen.

Ja, du sagst jetzt, dass der Gesamtpreis höher wird. Ich glaube das nicht. Das kommt natürlich immer so ein bisschen auf die Größe des Projekts an. Also wenn wir jetzt über eine Mini-Website sprechen oder ein kleines Tool, dann muss man sich auch überlegen, wie groß man das Ganze jetzt aufziehen will. Aber wenn wir jetzt über Projekte sprechen und davon haben wir genug, die auch über mehrere Jahre oder mal mindestens mehrere Monate laufen und entsprechend natürlich eine große Komplexität kriegen, wo auch mehrere Entwickler drin sitzen,

dann bin ich mir 100% sicher, dass die Kosten wesentlich geringer sind, wenn man mit insgesamt hoher Qualität, und jetzt haben wir eine gewisse Vorstellung davon, was das bedeutet, entwickelt.

Und ich kann zumindest von uns behaupten, dass ich mich nicht mehr daran erinnern kann, wann wir die letzte Deadline gerissen haben.

Also wir sind jetzt keine großen Fans von Deadlines, das heißt, wir setzen auf wenig. Aber grundsätzlich habe ich schon das Gefühl, wir können so die Zeiten, die wir beim Kunden auch rausgeben, einhalten. Und wir haben eigentlich keinen Stress bei uns in der Firma, das heißt, bei uns werden kaum Überstunden gemacht. Und das hängt schon alles damit zusammen, dass uns eben nicht ständig Bugs auf die Füße fallen oder wir kurz vor einem Release dann doch noch zig Funktionen feststellen, die nicht so gut funktionieren.

Wir sind jetzt gar nicht so richtig auf diese Projektmanagement-Themen eingegangen, dass wir zum Beispiel in manchen Projekten nach Scrum arbeiten und so weiter. Das ist jetzt für mich auch nicht der heilige Gral, aber das sind alles so Themen, die darauf einzahlen. Und ich glaube, insgesamt, und das beantwortet dann, denke ich, deine Frage, ist es am Ende wesentlich günstiger für den Kunden und vor allem sind hinterher bestenfalls auch alle zufrieden mit der Qualität, die eben hinten bei rauskommt.

Das ist jetzt schon ganz gut ins Fazit übergeleitet. Und ich glaube auch, dass trotz aller dieser Probleme und Hindernisse und zusätzlicher Systeme, die man sich mit solchen Verfahren an Bord holt, am Ende doch die Vorteile deutlich die Nachteile überwiegen.

Wenn ich da zurückdenke, wie gesagt, so ein altes Trauma mit irgendwelchen Releases, von denen man nicht wusste, was sie machen, sobald man dann erstmal vor allem Tests drin hat und eine gescheite Automatisierung, das Thema Builds und Deployments haben wir noch gar nicht angesprochen, das gibt, also zumindest mir als Entwickler ganz konkret, so ein Vertrauen in das eigene Produkt, dass ich dann auch dementsprechend mit Selbstbewusstsein gegenüber dem Kunden auftreten kann.

Genau, wir haben auch immer wieder Kunden, die so ein bisschen unsere Qualitätsansprüche da aufweichen wollen und im Wording machen wir das manchmal auch, aber hintenrum versuchen wir schon, die Qualität wirklich auch hochzuhalten, das zu tun und ich glaube, am Ende sind alle dann damit wirklich auch happy.

Bis wir jetzt einen Podcast drüber gemacht haben. Genau. Jetzt ist ein Geheimnis aufgeflogen. Vielleicht zum Abschluss, kannst du drei wichtige Punkte benennen, wenn jetzt jemand sagt, ich bin noch nicht ganz da angekommen, wo ich mal hin will mit der Qualität meiner eigenen Entwickler.

Oder mit der Qualität in unserem Team. Hast du so drei Punkte, die du rausgreifen könntest, wo du sagst, das ist jetzt das Allerwichtigste, was man als erstes angehen muss, wenn man sich so in die Richtung bewegen will?

Ich glaube, wenn man schon diese Idee hat und wenn man diesen Podcast auch hört mit der Motivation, was an der Qualität zu ändern, dann hat man schon, glaube ich, den wichtigsten Schritt gemacht, nämlich sich dessen bewusst zu machen.

Und diese ganzen Punkte, die wir jetzt gerade aufgezählt haben, die sind uns ja auch nicht von einem auf den anderen Tag in den Schoß gefallen, sondern jahrelang haben wir immer uns versucht zu verbessern, neue Systeme zu etablieren.

Manche haben besser funktioniert, manche nicht und sowas. Aber ich glaube, dieser initiale Impuls von, ich will gute Software machen, wie schaffe ich das und höre mir zum Beispiel so einen Podcast hier an, das ist eigentlich schon der wichtigste Schritt.

Ich glaube, wenn du mich auf zwei Dinge noch festnageln möchtest gegenüber dem Kunden, finde ich diesen Transparenzaspekt besonders wichtig, weil es ist keinem damit geholfen, wenn du, weiß ich nicht, in der Entwicklung irgendwelche Probleme hast und behältst das aber für dich, bis es dann irgendwann zu spät ist.

Sondern wenn ein Problem ist, rufst du den Kunden an, sagst Bescheid, wenn er wissen will, was irgendwas kostet, sagst ihm Bescheid, wenn der wissen will, wie der Fortschritt ist, sagst ihm Bescheid.

Am besten durch so ein transparentes Projekt-Tool, wie wir das haben. Und das tut manchmal auch weh, dem Kunden die Wahrheit zu sagen und wir versuchen das sehr konsequent. Genau, also von daher finde ich den Punkt nochmal richtig gut, den du hier einfach mal ins Fazit reinschmeißt. Genau, ich finde, wenn man damit auch früh anfängt, wenn man direkt so eine Vertrauensbasis hat, dann ist man auch viel schneller dabei, Fehler einzugestehen oder auf Probleme hinzuweisen, wenn das von Anfang an so eine Front mit verhärteten Kanten ist, dann fällt es einem vielleicht auch ein bisschen schwieriger.

Definitiv, ich sage ganz oft dem Kunden gegenüber so, oh Mist, das haben wir verbockt und lass das auch einfach so stehen, weil ich das, glaube ich, mit einem gewissen Selbstvertrauen aus einer guten Qualität, die wir entwickeln, sagen kann.

Und nicht dann fürchten muss, dass der Kunde sagt, boah, schon wieder oder so, sondern dass das wirklich ehrenden Vertrauen erzeugt, wenn man auch mal einen Fehler eingestehen kann. Ich glaube, als letzten Punkt ist mir dann noch diese CI-CD-Geschichte wichtig, das habe ich gerade ein bisschen ausformuliert. Also durch Pipelines und Automatisierung intrinsisch die Qualitätsvorstellungen sicherstellen, die man auch auf so einer Meta-Ebene hat.

Weil dadurch hat man dann die Ansprüche, die man als Firma hat, in den Code übertragen. Interessant, dass du die Punkte rausnimmst. Ich hätte jetzt gesagt, ganz knackig, macht Reviews und schreibt Unit-Tests, Punkt. Ja, insgesamt haben wir das Thema Qualität natürlich jetzt noch angerissen, das ist ganz klar. Also ich glaube, wir könnten uns jetzt noch eine Stunde weiter unterhalten darüber, was das jetzt heißt und könnten auf die einzelnen Themen noch näher eingehen. Und ich habe mir ja vorhin ein paar Stichpunkte gemacht und davon haben wir jetzt, glaube ich, die Hälfte gesagt. Also da kommt noch ganz viel, was zum Beispiel die Downsides sind von einer Software, die keine gute Qualität hat.

Dass das nicht nur ärgerlich, sondern auch teuer oder auch gefährlich sein kann. Wenn die nächsten drei Podcasts angeteasert. So ist es, genau. Also von daher soll das einfach ein guter Einstieg jetzt in das Thema Qualität in der Softwareentwicklung sein. Und ich denke, in allen weiteren Folgen, die so kommen, kommen wir zu 100 Prozent auch auf das Thema Qualität wieder zu sprechen. Und dann vielleicht in ein paar konkreteren Punkten auch. Und dann haben wir irgendwann mal ein vollständiges Bild, wenn wir bei Folge 25 angekommen sind. Als alte, graue Männer. Großartig. Ich habe mich gefreut, Felix.

Danke für deine Zeit. Kay, es hat richtig viel Spaß gemacht. Die erste Folge jetzt mit dir hier. Und ich denke, dann sehen wir uns in ein, zwei Wochen zum nächsten Thema. Großartig. Tschüss. Danke. Ciao, ciao.