KI macht schlechte Softwareentwicklung noch schlimmer – mit Govinda Fichtner

0:00 Hallo und herzlich willkommen zu Becoming CTO Secrets, dem Podcast von CTOs für CTOs. Und natürlich diejenigen, die es noch werden wollen. Ich bin Philipp Deutscher, externer CTO-Coach und Gründer der Becoming CTO Community. Heute spreche ich mit Govinda Fichtner. Er ist der CTO bei Quanos. Was Quanos macht, kann er gleich selber erzählen.

0:21 Und er hat rund 30 Jahre Erfahrung in der Softwareentwicklung. Wir sprechen darüber, warum nachhaltige Softwareentwicklung weit mehr ist als guter Code. In Brackets würde ich das jetzt mal setzen. Warum Architektur immer auch Organisationsdesign ist, ganz wichtig natürlich. Und weshalb AI Engineering Exzellenz nicht ersetzt.

0:38 Und ich liebe ja das Wort Exzellenz, sondern natürlich sogar verstärkt. Govinda, herzlich willkommen.

0:44 Wunderbar, hier zu sein. Freut mich auf unser Gespräch.

0:47 Und ich freue mich auch. Es hat ja ein bisschen gedauert, bis wir es hinbekommen haben, aber dafür wird es heute umso besser, haben wir uns vorgenommen. Deswegen freue ich mich wirklich sehr, dass du da bist. Ich habe gerade schon angekündigt, du bist der CTO bei Quanos. Vielleicht kannst du irgendwie schon mal ein, zwei Sätze dazu sagen, was macht Quanos, was ist deine Aufgabe?

1:02 Quanos ist eine Firma in der Nische, nämlich der technischen Dokumentation und dem AfterSale Service. Wir haben da eine Reihe von Produkten in unserem Produktportfolio. Das ist ein B2B-Geschäft. Kunden sind für uns sehr stark im deutschsprachigen Raum Maschinenbauer, zum Beispiel, Deutsche. Und wir bauen Software, die ihnen hilft, Dokumentationsprobleme zu lösen, Aufgaben zu lösen und Service dieser Maschinen, die in unterschiedlichsten Konstellationen genutzt werden, zu unterstützen mit Informationen, zum Beispiel für Servicetechniker.

1:39 Wir sind eine mittelständische Firma mit ca. 400 Mann und davon ungefähr 120 in der Technik, die ich leite.

1:48 Das heißt, du verantwortest auch all diese 120 Leute im Bereich IT, Softwareentwicklung und so weiter.

1:54 So ist es.

1:55 Sehr gut. Govinda, du blickst ja auch auf rund 30 Jahre Softwareentwicklung zurück. Und davon waren es über 20 Jahre als Individual Contributor, wenn ich das richtig sehe. Ich habe jetzt ja auch in der Einleitung, sage ich ja immer, der Podcast ist von CTOs für CTOs und diejenigen, die es noch werden wollen.

2:12 Ich habe auch heute erlebt, es gibt ja ganz viele, die hören den Podcast gerne und stellen dann trotzdem fest, sie wollen gar nie CTO werden. Du hast jetzt aber nach einer sehr langen Zeit in der IC-Rolle, hast du dann doch jetzt gesagt, jetzt will ich CTO werden. Oder wie genau war das?

2:26 Das hat sich über die Jahre so entwickelt. In gewisser Weise gab es nie eine Anleitung darüber, wie man CTO wird. Im Grunde sind die Aufgaben größer geworden. Ich habe, ich sag mal, mich immer dafür interessiert, wie Architektur aussieht, auch in meiner Individual Contributor-Rolle, und dann mit der Zeit festgestellt, dass Architektur und Organisation sehr eng verbunden sind.

2:51 Und so hat sich das dann Richtung, ich sag mal, Architekturrollen entwickelt, Chefarchitekturrollen in größeren Kontexten. Und irgendwann gab es dann den Sprung quasi in die erste CTO-Rolle.

3:03 Was hat da damals den Ausschlag gegeben dazu?

3:06 Am Ende das Bedürfnis, gute Produkte zu bauen und quasi die Möglichkeiten, die man dann in der Rolle als CTO hat, mit der Organisation zu arbeiten, die Rahmenbedingungen zu schaffen, dass Teams gut Software entwickeln können, die verschiedenen Stakeholder zusammenzubringen, die bei Softwareentwicklung eine Rolle spielen, Übersetzer zu sein zwischen diesen verschiedenen Funktionen, die man auf dem Unternehmen hat.

3:30 All diese Aspekte. Ist für mich eine sehr, sehr erfüllende Aufgabe.

3:35 Ja, ich stelle mir auch mal wieder die Frage und ich glaube viele da draußen auch, was bedeutet denn eigentlich gute Software zu bauen? Du warst ja auch in verschiedenen Kontexten unterwegs, du hast es gerade selber auch schon angedeutet. Konzern, Consulting, kleinere Firmen, Startups, Webentwicklung, Cloud, DevOps, war ja ganz eine Menge dabei.

3:51 Wo, also A, was bedeutet für dich gute Softwareentwicklung und wo hast du dieses Verständnis davon, was gute Softwareentwicklung sein soll, am meisten entwickelt oder wo hast du sie am meisten verstanden?

4:05 Ich denke, das, was für mich gute Softwareentwicklung ausmacht, ist tatsächlich nachhaltige Softwareentwicklung. Systeme, wo man in der Lage ist, über viele Jahre hinweg mit einer nachhaltigen Geschwindigkeit, mit einer nachhaltigen, gleichbleibenden guten Qualität zu liefern. Und das, was das für mich zu einem bedeutenden Thema gemacht hat, ist, dass ich über die Jahre natürlich viele Situationen erlebt habe, viele Umstände, wo man gesehen hat, wie Systeme quasi über die Jahre, manchmal Jahrzehnte Stück für Stück verfallen sind und damit dann ganz viele, ich sag mal, Probleme einhergegangen sind, die man dann, ich sage mal, als Organisation, als Teams kompensieren musste und wo man gegen diese

4:50 Strukturen und gegen Versäumnisse oftmals dann anarbeiten musste.

4:56 Wie sieht das dann konkret aus? Aber ich meine, die meisten Entwickler, die fangen ja nicht an, von heute auf morgen schlechten, einfach so schlechten Code zu schreiben. Ganz viele, also die meisten zumindest nicht, weil ganz vielen ist dann natürlich schnell, wird das, wird er die Hand gehoben, wird gesagt, ja, wir würden ja gerne, aber wir kriegen immer so viel Druck und wir müssen ja schnell machen und deswegen haben wir ganz viele technische Schulden.

5:14 Und in dieser Gemengelage zwischen der Manager, der schreibt am Ende keinen Code, der macht vielleicht Druck, aber der Entwickler ist derjenige, der den Code schreibt und der die Legacy-Software dann am Ende des Tages auch mit zu verantworten hat. So, in dieser Gemengelage ist es ja schwierig, einen Schuldigen auszumachen, an dem man jetzt festmacht, was jetzt, wie man es aus diesem Teufelskreis rauskommt.

5:34 Wie gehst du denn damit um, zwischen Anforderungen, die auch manchmal unfair sind vor dem zeitlichen Horizont und ja der Verantwortung, die Entwickler auch mit übernehmen müssen für die Software, die sie entwickeln, auch wenn sie mal zu technischen Schulden führt?

5:49 Ich denke, dass viele dieser Herausforderungen dadurch entstehen, dass natürlich verschiedene Stakeholder in so einer Gemengenlage, also in der Gemengelage der Softwareentwicklung miteinander zusammenarbeiten, aus unterschiedlichen Blickwinkeln, aus unterschiedlichen Funktionen des Unternehmens, von der Sales-Seite über die Marketing-Seite hin zu, ich sag mal, Customer Support-Seite, dann den technischen Teams, die diese Dinge bauen.

6:16 Und jeder sieht natürlich immer nur einen Teil, ich sag mal, des größeren Ganzen. Und ich sag mal, dabei werden oft, ich sag mal, wird es systemlich ganzheitlich gesehen und betrachtet und entwickelt. Das ist das eine. Und das andere ist, dass natürlich auch zu unterschiedlichen Zeiten unterschiedliche Prioritäten existieren, die quasi Teams in eine bestimmte Richtung drücken.

6:40 Und das muss, ich sag mal, aus meiner Sicht ist Teil einer nachhaltigen Softwareentwicklungsstrategie, diese immer auszubalancieren. Und ich sage mal, das mentale Bild, was für mich da ganz wesentlich ist, oft für viele Stakeholder, die nicht direkt aus der Technik kommen, was die sehen, sind die Features, die Produkteigenschaften, das ist die Spitze des Eisbergs.

7:03 Aber tatsächlich die Dinge, die nachhaltige Softwareentwicklung wesentlich beeinflussen, das sind die Elemente, die unterhalb der Wasserlinie sind. Und das ist der weit größere Teil des Eisbergs. Und das, was oft passiert, ist, dass der sichtbare Teil viel Aufmerksamkeit bekommt, strategisch bearbeitet wird, aber der unter der Wasserlinie liegende Anteil nicht.

7:25 Also ich meine, woran merkt man, dass Softwareentwicklung dann nicht nachhaltig ist? Ist das dann einfach, wenn die Teile, die unter der Wasseroberfläche liegen, nicht bearbeitet werden oder gibt es da noch mehr?

7:34 Merkt man vor allem daran, dass Entwicklungsgeschwindigkeit, die vielleicht, ich sag mal, zum Start einer Produktentwicklung hoch ist, über die Jahre langsamer wird, signifikant langsamer wird, Änderungen, die vorher möglicherweise eine Woche gebraucht haben, dann plötzlich drei Wochen brauchen oder noch länger brauchen, vielleicht gar nicht mehr sinnvoll, also kommerziell und unter Aufwandsgesichtspunkten überhaupt nicht mehr möglich sind.

8:00 Teams, Angst haben vor Veränderungen, das sind alles so Aspekte. Und dann sind so Aspekte vielleicht auch von Dingen, die nur dann relevant werden, wenn sie plötzlich nicht mehr da sind, wie zum Beispiel Sicherheit. In Sicherheit zu investieren regelmäßig mag verlieren gegen andere, ich sag mal, Wünsche wie schnell ein Feature zu bauen.

8:23 Aber wenn dann mal ein System gehackt wird, Daten verloren oder kompromittiert ein System ist, dann ist das natürlich ein großes Ding. Und ich sag mal, hat tatsächlich auch eine aktuelle Relevanz. Wir haben den Cyber Resilience Act, der jetzt aktiv wird, wo quasi Unternehmen, die IT-Produkte produzieren, auch in der Verantwortung sind, Sicherheitslücken, die bekannt werden, zu kommunizieren und dann auch zeitnah zu beheben?

8:54 Und damit wird es dann auch ein, ich sage mal, aus juristischer Sicht ein wesentliches Anliegen.

9:01 Wie kommunizierst du jetzt dieses nachhaltige Softwareentwicklungsmodell oder auch das Eisberg-Modell, das du jetzt gerade genannt hast, wie kommunizierst du das mit einem CEO oder mit einem Product Leader, der vielleicht nicht immer auf dem Schirm hat, dass Architektur, Modularität, nicht funktionale Anforderungen, dass das Aufwand erfordert, dass das Kosten verursacht.

9:26 Wie gehst du damit um?

9:27 Man kann sich vorstellen wie ein Schiff, ja. Also da gibt es den Teil des Schiffs, der unter der Wasseroberfläche ist, der nicht gesehen wird, wo man nicht möglich leicht bereitwillig rein investiert. Aber ich sag mal, in dem Moment, wo quasi dieser Teil beschädigt ist, dann geht das ganze Schiff unter.

9:45 Und wesentliche Ziele, die man hat, kann man nicht mehr erfüllen. Sicherheit ist zum Beispiel ein Thema da sicherlich, Skalierbarkeit ist ein Thema, Wartbarkeit, Erweiterbarkeit, das sind alles Themen, die mögen in den Anfängen, in den ersten Jahren vielleicht von komplexer Produktentwicklung keine Rolle spielen.

10:05 Aber in dem, über die Jahre hinweg, werden sie dann ganz wesentlich. Und am Ende führt es dann möglicherweise dazu, dass man ein Produkt komplett ersetzen muss und dann all die möglicherweise Risiken eines Big Bang-Releases hat, wo man das eine System komplett durch ein neues System ersetzen muss.

10:24 Wie machst du denn sowas sichtbar dann gegenüber dem CEO? Gerade wenn es um das Thema Wartbarkeit geht oder Erweiterbarkeit, ist das, ja, der, du kannst ja sagen, ja, wir werden jetzt einmal nicht mehr so gut erweiterbar wie vorher. Dann sagt er, ja, aber wo sehe ich denn das? Wie kann ich denn unterscheiden, dass wir, wann sind wir denn wieder gut?

10:44 Aus meiner Sicht ist das natürlich ein Spektrum. Das ist, da gibt es nicht eine Antwort drauf für jede Situation, was funktioniert. Aber ich sage mal, ein Aspekt, der mir tatsächlich wichtig ist, sind die Dora-Metrigen und quasi Metriken, die quasi Geschwindigkeit ausdrücken, auf der einen Seite. Das sind zwei der üblichen vier Dora-Metriken, und Stabilität, also betriebliche Stabilität.

11:09 Und dann ist es natürlich in dem Kontext auch eine Frage, ist es jetzt eine klassische On-Prem-Software, die quasi der Kunde kauft und dann selbst sich darum kümmert um den Betrieb, oder ist es quasi ein SaaS-Kontext, wo man sowohl als Team für die Entwicklung als auch für den Betrieb zuständig ist. Also die Dora-Metriken und ich sag mal, die entsprechenden Industrie, also die Einordnung unserer Industrie, was quasi hier gute Performance ist und was schlechte darstellt.

11:41 Und in den letzten Jahren habe ich angefangen, auch noch ein weiteres Metrigen-Framework als nützlich zu achten, was das North Star-Framework ist. Von einer Firma bekannt gemacht, die sich Amplitude nennt. Und die im Grunde das, was DORH für die Engineering-Arbeit ist, ausweitet auf den Produktmanagement-Aspekt.

12:05 Bauen wir tatsächlich, ich sag mal, Funktionalität, Produktaspekte, die einen echten Wert für Kunden haben. Und sind wir in der Lage, das zu artikulieren, zu messen, zu tracken und können wir das dann in Relation setzen zu unseren eigentlich am Ende immer beständigen Trade-Off, also Abwägungsentscheidungen, die wir machen, aus einer technischen Sicht.

12:26 Siehst du da immer wiederkehrende Muster? Also gerade wenn du sagst, am Anfang sind Teams immer sehr schnell, gerade so in den ersten ein bis zwei Jahren und danach werden sie immer langsamer. So, was passiert denn in diesen Phasen typischerweise im System? Ist das etwas, was du immer wiederkehrende Muster siehst, oder ist es dann doch immer sehr stark kontextabhängig und situationsbezogen?

12:50 Warum sie langsamer werden?

12:52 Naja, ich sag mal, wiederkehrende Muster sind da sicherlich sichtbar. Ich persönlich denke, dass es eine gewisse Aspekte, Praktiken, Methodiken gibt, wenn man die von Anfang an, auch wenn das System in den, ich sag mal, klein ist, das Produkt in den Anfängen ist, wenn man die anwendet und da das Niveau immer, ich sag mal, auf einem hohen Level hält, dann erodiert im Grunde nie der Teil unter dem Eisberg wirklich, sondern wächst in seiner Qualität mit dem, was quasi als Spitze des Eisbergs über der Wasseroberfläche zu sehen ist.

13:28 Also das ist ein Aspekt. Dann denke ich, ein weiterer Aspekt ist sicherlich die Organisation, die Teamstruktur, und damit quasi das Thema Conway's Law, also dass quasi die Kommunikationsstrukturen von Teams am Ende auch die Architektur maßgeblich beeinflussen. Also das sind aus meiner Sicht ganz, ganz wesentliche Aspekte.

13:50 Und der Umgang mit technischer und wenn man so will, auch organisatorischer Schuld, dass man quasi bewusst dieses Spielfeld betrachtet, wenn man, ich sag mal, technische Schuld beständig quasi eingeht, Abkürzungen nimmt, ohne dann je ein Verständnis dafür zu haben, was man an Schuld angehäuft hat und was das für, ich sag mal, Zinszahlungen sind, die sich dadurch ergeben, dann hat man natürlich auch kein Verständnis dafür und keine Chance, das wieder auch abzutragen.

14:26 Und dann erschlägt einen irgendwann diese Zinslast. Ähnlich wie möglicherweise Volkswirtschaften zu viele Schulden anhäufen und dann, so wie jetzt die USA, feststellen, dass die Zinszahlungen immer größer werden und ihren Handlungsspielraum einschränken. Also ich denke, das ist tatsächlich ein gutes Beispiel.

14:43 Der Handlungsspielraum wird sukzessive mehr und mehr eingeschränkt. Wenn man diese technischen Schuld und organisatorischen Schuldaspekte nicht managt. Oft, denke ich, ist das auch ein Artikulationsthema. Also erstens eine Wahrnehmung dafür zu haben und B, das dann zu artikulieren und zwischen verschiedenen Stakeholder-Gruppen sichtbar zu machen und dann zu einem beständigen Kunden Neu ausbalancieren zu bringen.

15:10 Wie schmal ist der Grad zwischen Overengineering und nachhaltiger Softwareentwicklung? Weil Engineers auch immer wieder dazu tendieren, auch mal in Overengineering abzurutschen und nach der perfekten Lösung zu schrieben und zu streben. Und dabei wäre eine andere Lösung good enough gewesen und wäre vielleicht sogar auch nachhaltig gewesen.

15:28 Ja, also aus meiner Sicht ganz wesentlich, das ist ein Fakt. Wir als Techniker, wir haben eine gewisse Verspieltheit, wir haben eine Faszination mit Technik und wir wollen natürlich wissen, was möglich ist. Und ich denke, das ist ein wesentlicher Aspekt von Erfahrung und Seniorität, beurteilen zu können, wie viel man braucht, dass man da iterativ, inkrementell an phasenweise, an Aspekte herangeht.

15:55 Es gibt ja dieses Würzel auch, Jagny, you ain't gonna need it. Ich denke, das ist ganz wesentlich. Also im Grunde, wenn man davon ausgeht, dass ein System skalieren muss, dann ist es möglicherweise die richtige Entscheidung zu sagen, okay, ich gehe davon aus, dass es um den Faktor 10 skalieren muss, muss es um den Faktor 100 skalieren können, muss ich entsprechend, bevor ich tatsächlich die Datenlage habe, das System weiter optimieren.

16:19 Ich glaube nicht. Wichtig aus meiner Sicht ist eher, dass man ein Messsystem hat, ein Observability-Setup, in dem man frühzeitig erkennt, was die Faktoren sind, die zum Beispiel Skalierbarkeit oder Performance ausmachen und dass man mit diesen Informationen dann systematisch und frühzeitig erkennen kann, in welche Richtung die Reise geht und man reagieren kann.

16:42 Also die Reaktionsfähigkeit, die Lernfähigkeit des Systems erscheint mir da der wichtige Aspekt zu sein.

16:48 Ja, Observability-Setup hast du genannt. Was nutzt du denn dafür typischerweise?

16:53 Observability, gut, das hat sich über die, ich sag mal, Jahrzehnte sehr stark auch verändert, zusammen mit, ich sag mal, den großen Trends unserer Industrie. Früher gab es quasi die sehr Infrastruktur-serverseitig getriebene Monitoringlösung, wie zum Beispiel auch die von der Fana Tesla, für die ich eine Zeit lang gearbeitet habe.

17:15 Und irgendwann kam dann mit New Relic die, ich sag mal, application-zentrierten Monitoring-Systeme, die entwicklerzentrierten Monitoring-Systeme. Und die bevorzuge ich deswegen, weil sie im Grunde einzahlen auf, ich sag mal, das DevOps-Modell. Also you build it, you run it, die quasi Auflösung von Silos zwischen Entwicklung und Betrieb.

17:41 Das heißt, wenn die Entwickler quasi in der Lage sind für die wesentlichen Aspekte dessen, was eine gut funktionierende Anwendung ist, ein Observability-Setup haben, einen Feedback-Loop haben, dann ist das am Ende das, was sicherstellt, dass das System gut funktioniert. Benutzt habe ich, ich sage mal, in meiner Karriere und die Teams, mit denen ich gearbeitet habe, vieles, ob das Datadoc war, New Relic war, Scout war, es gibt auch immer wieder neue Systeme, Open Source Systeme, The Looks Good To Me Stack, also Loki, Grafana, solche Sachen zum Beispiel, mit dem Ganzen, ich sag mal, Entwicklungen rund um Container aus den letzten Jahren.

18:24 Da gibt es nicht das eine Tool, es sind quasi Werkzeuge in einer Werkzeugkiste. Man muss halt das wählen, was in dem jeweiligen Kontext am besten passt.

18:33 Von den Non-Functional Requirements, welche würdest du denn jetzt in einem wachsenden Softwareunternehmen besonders früh ernst nehmen?

18:44 Definitiv Sicherheit. Dann die Wartbarkeit und die Testbarkeit. Also Testbarkeit aus meiner Sicht ist tatsächlich eines der wichtigsten Dinge, weil die am Ende darüber entscheidet, ob das System gut designt ist. Wenn sie es nicht gut testen lässt, also wenn Testen quasi eher ein Nachgedanke ist als von Anfang an dabei, dann ist es viel, viel schwieriger, gute Testing-Strategie, Testautomatisierungsstrategie zu etablieren und am Ende quasi auch die Qualität des Produktes sicherzustellen.

19:19 Und das ist ein wesentlicher Faktor, der dann später darüber bestimmt, mit welcher Geschwindigkeit man ein System verändern kann, mit welcher Zuversicht man ein System verändern kann und ob man so Praktiken wie Continuous Delivery einführen kann und wo man da in dem Spektrum im Sinne von Geschwindigkeit sich bewegt.

19:40 Release man alle drei Monate, release man jeden Monat, release man wöchentlich oder released man möglicherwehr am Tag. Und aus meiner Sicht, das bevorzugte Modell wäre definitiv in der Regel zu sagen, ich kann mehrmals am Tag releasen und deployen. Und das ist am Ende dann auch wieder ein Hinweis darauf, dass das Setup hinten dran, das CICD-Setup, die Qualitätssicherung, die Testautomatisierung, dass diese Aspekte alle einen gewissen Reifegrad haben, eine Qualität.

20:10 Du hast auch, du hast jetzt eben schon von Conway's Law gesprochen. Und ich habe dich ja auch so verstanden, auch im Vorgespräch, dass Architektur früher für dich noch viel stärker code-orientiert war. Also es ging dann um Methode, es ging um Klassen, Module. Heute betrachtest du das eher stärker über die Organisation und Teamstrukturen, deswegen eben Conway's Law.

20:30 Was war denn da der entscheidende Perspektivwechsel?

20:33 Ja, der entscheidende Perspektivwechsel war im Grunde zu sehen, dass man möglicherweise immer wieder die gleichen Probleme, auch wenn man ein Systeme refactored hat, bekommen hat. Und dass diese Probleme gar nicht technischer Natur waren, sondern dass die eher damit zu tun hatten, wie quasi die Systeme geschnitten waren.

20:56 Und die Systeme sind oft quasi nach den Team-Kommunikationswegen geschnitten. Und wenn das dann dazu führt, dass wenn man Veränderungen machen muss in einem Bereich, aber am Ende mit drei Teams zusammenarbeiten muss, einen großen Koordinations- und Kommunikationsbedarf und Aufwand hat und wesentliche Probleme nur sehr, sehr zäh und schwierig zu lösen sind, dann ist das ein Hinweis darauf, dass tatsächlich das Ganze eben nicht nur ein technisches Problem ist, sondern auch ein organisatorisches Thema, wie die Teams geschnitten sind.

21:34 Wie zeigt sich denn dann Conway's Law in so im realen Engineering-Organisation?

21:39 Naja, so wie ich es gerade sagte, einerseits quasi Koordinierungsaufwand, dass einfache Veränderungen nicht an einer Stelle durch ein Team bewirkt werden können, sondern möglicherweise über mehrere Teams hinweg passieren müssen, dass es dort einen hohen Koordinierungsaufwand gibt, Friktion. Ich sag mal, prinzipiell ist sowieso.

22:00 Meine Erfahrung so, dass ich sage mal, Zusammenarbeit üblicherweise vergleichsweise einfach und gut funktioniert innerhalb von einem Team, aber in dem Moment, wo es über Teamgrenzen hinweg geht, wird es schwieriger. Und dann ist es natürlich auch ein Aspekt davon, wie quasi diese Software entwickelt und betrieben und ausgerollt wird.

22:18 In einem, ich sag mal, SAS-Cloud-Setup ist es dann so, dass man die Software am Ende auch deployt und die Frage ist dann, müssen da wieder drei Teams zusammenarbeiten, um was zu deployen oder können diese Deployments unabhängig passieren? Hat es eine Art von Microservice-Architektur oder zumindest eine Art von Modularisierung oder ist alles im Grunde ein Monolith, ein Big Ball of Mud und das macht diese Art von Arbeitsteilung schwer?

22:46 Ich habe jetzt, ich rede ja tagtäglich mit CTOs in allen möglichen Kontexten und ich kenne nicht wenige, die sagen, dass es Ihnen schwerfällt zu verstehen, wenn jetzt dann Teamstruktur gegen die gewünschte Systemarchitektur arbeitet? So, wie, also Ihnen fällt das schwer, sowas zu erkennen und auch sichtbar zu machen und dann darauf zu reagieren.

23:11 Hast du einen Vorschlag, wie man sich dem Thema nähern kann? Weil das ist für viele doch recht abstrakt, zu entscheiden, wann meine Organisation sich negativ auf meine Architektur niederschlägt oder nicht?

23:23 Es sind wahrscheinlich auch verschiedene Antworten, aber ich sage mal, das, wo für mich eine große Hilfe ist, wie ich darüber denke, ist quasi Domain-Driven Design. Also quasi die Idee, wie ich ein komplexeres, großes System in Teildomänen zerteile und wie ich dann quasi diese Teildomänen, üblicherweise Services, die das Gesamtsystem ausmachen, wie die verteilt sind über die Teams und wie die Verantwortlichkeit da gestaltet ist.

23:53 Also das ist aus meiner Sicht ein wesentlicher Aspekt. Ich persönlich bin auch sehr beeinflusst durch die Ideen von Team Topologies. Das ist ein Buch, was in den letzten Jahren sehr populär geworden ist, was quasi von sogenannten Stream-Aligned Teams spricht. Also genau auch so vor dem Hintergrund von Conway's Law, Domain-Driven Design, diesem Domain-Verständnis.

24:17 Wie design ich quasi Organisation and Architektur und die Services zusammen? Und was sind möglicherweise, die nicht in einem Stream-Aligned Team organisiert sein sollten, sondern in einem Plattform-Team zum Beispiel, was quasi spezialisierte Produktaspekte verantwortet, auf die dann andere Teams aufbauen?

24:43 Und gewisserweise ist das auch ein Trend der letzten zwei, drei Jahre, nämlich sogenannte Internal Developer Platforms zu kreieren. Ich denke, das ist auch eine Entwicklung der letzten 20 Jahre, die kognitive Last, die Komplexität dessen, was wir an Technik verantworten als Teams, die ist massiv gewachsen.

24:58 Ist das für dich auch ein gutes Beispiel für so eine Art Reverse Conway, was du da gerade beschrieben hast mit den Team Topologies? Also dass die Teams ganz bewusst dann so zu strukturieren, dass eine gewünschte Architektur wahrscheinlicher wird?

25:11 Ja, absolut. Also ich bin, das ist ein wesentlicher Unterschied, ich sag mal, in der Art, wie ich über diese Architekturaspekte denke. Wie du vorhin schon sagtest, in den ersten vielleicht sogar Jahrzehnten meiner Karriere habe ich Architektur als eine technische Sache betrachtet. Die Modularisierung, die Klassen, die Methoden, ich sage mal, alles, was man so mit Clean Code verbindet, als wesentlichen Einflussfaktor zu sehen.

25:38 Aber tatsächlich bin ich heute an dem Punkt, wo ich sage, das geht nicht ohne Organisation. Man muss die Teams bei größeren Herausforderungen quasi auch mit berücksichtigen und Andersformen ausprägen.

25:54 Wie gestaltest du denn als CTO das Thema? Du hast ja eben schon von Kommunikations gesprochen und wie Kommunikation auch dazu beiträgt oder sich in technischen Entscheidungen niederschlägt, in Architekturentscheidungen und so weiter, das ist natürlich auch geprägt durch Organisation, welches Team darf mit welchem reden.

26:10 Welche, ja, wie gestaltest du das als CTO? Dass du, also du musst ja erstmal Kommunikationsmuster erkennen, um danach auch sagen zu können, na, das hat jetzt hier Einfluss auf diese und jene Architekturentscheidungen und das gefällt mir nicht, in welche Richtung das geht, also greife ich ein, um. Oder wie machst du das?

26:26 Naja, ich denke, es ist gut, wenn man was hat, was ich als technische Führung bezeichnen würde, die klar ausgeprägt ist in einer Organisation. Jetzt eine Organisation mit 120 Mann, mit 14 Teams in meinem Fall, braucht es ein gewisses Maß an gemeinsamem Verständnis dessen, was das Spielfeld ist. Also was sind die technischen Standards, was macht Qualität aus, was sind unsere Herausforderungen als Organisation in Bezug auf die Produkte und wie die Produkte technisch realisiert werden.

27:04 Das muss klar artikuliert und abgestimmt sein. Das ist für mich ein wesentlicher Aspekt. Und dann, ich sag mal, wesentliche Play zu haben, die für Aspekte wie Architektur, Security, Compliance, Ways of Working zuständig sind und die prägen. Also quasi, ich sag mal, Guardrails, Leitplanken etablieren, gewisse Grundstandards, ja.

27:33 Nicht mit dem Ziel, dass die einzelnen Teams am Ende überhaupt keine Entscheidungsspielräume mehr haben, sondern dass quasi das Maß der Standardisierung, die Qualitätserwartungen, dass die klar sichtbar sind. Und die Strategie. Weil am Ende ist alles immer auch ein Faktor, wo die Dinge sich über den Zeitstrahl hinweg verändern und das, was möglicherweise vor drei Jahren wesentliche Aspekte waren, sind jetzt ganz andere.

28:01 Und das muss überall sichtbar werden.

28:04 Genau, und das vielleicht noch als letzte Frage zu dem Punkt, weil das ist, da beschäftigt mich tatsächlich auch die Frage, wann ist denn ein Problem, wirklich ein Architekturproblem und wann ist es ein Organisationsproblem oder lässt sich das gar nicht so klar voneinander trennen?

28:19 Ich denke, manchmal lässt sich das nicht so klar voneinander trennen. Ich denke, das ist immer sehr abhängig vom Kontext. Man kann ein komplexes System haben, wo es Sinn macht, zum Beispiel eine Bankroservice-Architektur zu haben, damit man quasi eine größere Arbeitsteilung realisieren kann, eine größere Parallelisierung, das unabhängige Bewegen einzelner Teams.

28:46 Aber möglicherweicht es genauso Sinn, in anderen Konstellationen ein Majestic Monolith zu haben, wie die letzten zwei, drei Jahre wieder von bestimmten Größen in unserer Industrie quasi postuliert wird. Und ich denke, das ist völlig korrekt. Es gibt nicht quasi die eine Lösung, die für alle Konstellationen passt.

29:08 Es gibt immer nur Trade-off-Entscheidungen, weil auch eine Microservice-Architektur bringt eine Komplexität mit. Container-Architekturen bringen eine Komplexität von verteilten Architekturen, Netzwerkaspekten mit, die möglicherweise nicht in allen Fällen sinnvoll sind. Monorepo versus einem, ich sag mal, eine Repo-Landschaft von 20, 30 Repos für ein Produkt.

29:34 Und auch das ist nicht nur in der Vergangenheit wesentlich gewesen, sondern ist jetzt tatsächlich auch mit AI wieder ein Thema. Wenn man mit AI und Cloud Code arbeitet, dann ist die Frage, sind all die Informationen, die ich habe, in einem Repo oder sind die verteilt über 20? Eine Frage auch, die darüber entscheidet, wie effizient die Zusammenarbeit mit AI an der Codebasis sein kann.

29:57 Also aus meiner Sicht, es gibt nicht die eine Antwort.

30:01 Ja, und wenn wir auch jetzt schon so viel über Softwareentwicklung auch philosophieren oder das versuchen abzugrenzen, so ab dem Jahr, ich glaube es war 2005, kann man, glaube ich, sagen, weil das Thema Cloud ist da sehr, sehr stark populär geworden. Du warst sehr früh bei den Themen dabei, bei AWS, bei Cloud-Themen und so weiter.

30:24 Wie hat denn das Thema Cloud-Softwareentwicklung grundsätzlich verändert?

30:29 Es war eine wunderbare Veränderung in gewisser Weise. Aufbauend eigentlich für mich in der Wahrnehmung auf, ich sage mal, den Fortschritten rund um Virtualisierung und nicht zufälligerweise, offensichtlich waren auch die ersten Cloud-Dienste zum Beispiel Easy2 oder S3 bei ABS. Und das hat eine große Veränderung bewirkt, weil wenn man vorher Infrastruktur quasi als, ich sag mal, Deployment-Ziel für ein Softwareprodukt zur Verfügung stellen musste, dann waren damit oft, ich sage mal, wochenlange Prozesse verbunden, quasi diese Infrastruktur zu planen, zu bestellen, zur Verfügung zu stellen, aufzubauen, in Betrieb zu nehmen.

31:13 Und das hat sich natürlich massiv gewandelt mit Cloud. Da ist das quasi nur noch dann eine Frage von einem API-Call gewesen und möglicherweise ein paar Minuten, bis ein System dann quasi einsatz- und betriebsbereit war. Und das hat dann dazu geführt, dass die Automatisierungsmöglichkeiten quasi massiv größer geworden sind.

31:37 Alle Aspekte, wie man das zur Verfügung stellen von Infrastruktur automatisiert machen kann, testen kann, wieder abreißen kann. Das bedeutet am Ende auch, dass man natürlich viel schneller experimentieren kann. Also dass quasi das Lernen günstiger geworden ist, dass solche Infrastruktur hoch und runter skalieren konnte, on demand, je nachdem, was halt quasi die Workload war zu einem bestimmten Zeitpunkt.

32:06 Und das hat dann aus meiner Sicht natürlich auch beigetragen dazu, dass man agile Methoden besser einsetzen konnte, ich sage mal, auf Basis von agilen Methoden iterativ, inkrementell arbeiten konnte. Weil man viele Dinge nicht, ich sage mal, mit einem längeren Zeithorizont vorhersehen und planen musste, sondern sich das entwickeln lassen konnte.

32:33 Und wie hängen die denn aus deiner Sicht zusammen, diese Themen? Also es ist ja nicht nur Cloud und Agilität, es ist das Thema DevOps auch noch mit dazu. So, die hängen ja, die hängen zusammen und die sind sehr stark miteinander verknüpft, das sagst du ja auch. Wie hängen die denn zusammen? Absolut.

32:47 Die hängen aus meiner Sicht sehr stark zusammen, weil in dem Moment, wo ich diese Infrastruktur automatisiert deployen kann und dazu dann das entsprechende Observability-Harness deployen kann, dann habe ich immer, ich sag mal, sehr gute Feedback-Qualität, habe einen engen Feedback-Loop. Es ermöglicht, dass das, was quasi Infrastruktur bedeutet, das zu programmieren.

33:11 Infrastructure as a Code war plötzlich eine Programmieraufgabe und keine Administrationsaufgabe, nichts, was manuell war. Es hat im Grunde die Mauer entfernt, die zwischen Entwicklungs- und Betriebseinheiten existiert, hat die Silos aufgelöst und am Ende war quasi das, was vorher zwei Funktionen waren, zwei Teams waren, ist zu einem verschmolzen.

33:35 Und das gibt es natürlich in unterschiedlichen Ausprägungen, manchmal in der, dass ein Team einen DevOps-Engenieer hat, der für diese, ich sag mal, operativen Aspekte mehr verantwortlich ist. Aber ich persönlich bevorzuge das Modell, wo quasi Entwickler, also wo der Hut, den man aufhat als Ingenieur in einem Team, ständig wechselt zwischen entwicklungs- und operativen Aspekten, mehrmals täglich.

33:59 Vielleicht dutzende Male am Tag. Und man diese Aspekte in dem Betreiben des Produktes fließend ineinander übergehen. Und das bedeutet, dass natürlich auch der Schmerz, den man hat im Betrieb von Systemen, dass der sichtbar ist und dass man dann sehr schnell auch quasi sieht, wie das, was man entwickelt hat, zu gewissen Problemen im Betrieb führt.

34:23 Und das ist dann quasi ein wesentlicher Teil von dem Wert für mich, was DevOps ausmacht, dass diese Signalwirkung stark ist, dass man das Signal sofort aufnehmen kann und umsetzen kann in eine Lösung, in einer Person, die quasi nach dem DevOps-Modell arbeitet.

34:42 Wie siehst du denn das Thema Agilität? Da hast du es jetzt eben auch nochmal angesprochen, dass es auch wichtig ist und so. Wie siehst du das jetzt gerade auch im Jahr 2026? Wird das immer wichtiger? Verliert es aktuell so ein bisschen an Bedeutung oder gerät den Hintergrund vor dem vor der immer krasser Um sich greifenden Agentica I, SDLC, Invasion?

35:06 Ja, für mich ist das genauso relevant wie vor 20 Jahren. Ich habe meine Karriere ja in Zeiten gestartet, wo wir nach Wasserfall gearbeitet haben, komplexe Projekte bei Systems bei Telekom gemacht haben mit Wasserfall, mit V-Modellen, mit RURP, Regional Unified Process. Und all die Probleme, die da existieren, die habe ich aus erster Hand kennengelernt und für mich sind nach wie vor die Prinzipien agile Entwicklung wesentlich und relevant.

35:38 Der wesentliche Grund dafür ist, dass wir oft als Menschen, als Anforder schlecht sind, alle Aspekte, die wir von einem System erwarten, klar zu artikulieren. Manchmal glauben wir, wir wissen es und am Ende stellt sich dann doch heraus, wenn unsere Nutzer, unsere Kunden es benutzen, dass es doch ganz anders ist.

35:59 Und deswegen glaube ich, das ist ein wesentlicher Aspekt von inkrementeller, iterativer Entwicklung, sich dem Stück für Stück anzunähern, was tatsächlich das ist, was gebraucht wird. Das ist der eine Faktor. Und dann da, wo man lernt, dass bestimmte Aspekte wichtig sind, die man noch nicht berücksichtigt hat, dass man die schnell hinzufügen kann.

36:18 Und ich glaube, dass dieser Aspekt auch in einem Zeitalter von AI-unterstützter Entwicklung ganz wesentlich ist, weil wir bewegen uns potenziell noch schneller. Code-Generierung geht noch schneller. Aber dieses grundsätzliche menschliche Problem, quasi Anforderungen zu artikulieren, Systeme zu bauen, die die Jobs erfüllen, die sie erfüllen sollen, diese Problematik geht nicht weg.

36:42 Ja. Du hast aber gerade was die Anforderungen angeht, gibt es jetzt ja einige, die sagen würden, naja, aber die Anforderungen, die macht mir jetzt die AI, die kann sie vollständiger und lückenloser erstellen, wie vorher auch. Klar, da stellt sich die Frage, ist das alles immer notwendig und haben wir dadurch nicht ganz viel Scope-Cree?

36:59 Aber was jetzt die Anforderungen angeht, hat sich doch der, da hat sich doch jetzt vieles vereinfacht oder würdest du das anders sehen?

37:07 Anforderungen im Sinne von Requirement Engineering, also im Sinne von dem, was ein Kunde von einem Produkt will. Woher weiß das die AI? Woher weiß die AI, was ich sag mal, die ganzen Jobs sind, die ein technischer Redakteur in der Nische der technischen Dokumentation benötigt, wie das Produkt dort eingesetzt wird bei Kunden, wie sich verschiedene Kunden unterscheiden in ihren jeweiligen Handlungsfeldern.

37:33 Die AI braucht Kontext dafür, genau. Die muss man ja zur Verfügung stellen, richtig.

37:38 So ist es. Und deswegen bin ich auch der Meinung, ich sag mal, für mich hat Kontext bei AI unterstützt die Entwicklung zwei Komponenten. Das eine ist Engineering Kontext, also Architektur, Qualitätsstandards, Ways of Working, all diese Aspekte zum Beispiel. Aber es ist auch Produktkontext, also quasi, was ist die Produktmission, was ist die UX-UI-Erfahrung, die realisiert werden soll.

38:04 Was ist der Markt, die Domäne, die Kunden, die Probleme, die sie lösen wollen. Und erst wenn all diese Dinge zusammenkommen, aus meiner Sicht, wird AI ihr echtes, ihr volles Potenzial realisieren können.

38:18 Okay. Jetzt ist natürlich Scrum nicht gleich Agile, aber Das ist ein wichtiger Punkt, ja. Genau, das ist aber was ich erlebe gerade in der Industrie, ist ein massiver Rückgang von Scrum-Teams, speziell dort, wo das Level an Autonomie und Automatisierung mit Agentic AI-Workflows zunimmt. Siehst du das auch oder ist das, oder glaubst du, das ist nur ein vorübergehender Effekt, der sich wieder einstellen wird?

38:51 Also ich glaube, ich sehe das genauso, dass Scrum vielfach im Moment kritisiert wird oder auch abgelehnt wird. Ich denke, man muss da sehr stark unterscheiden zwischen Agilität, also agile Entwicklungsmethodiken und den Prinzipien des agilen Manifests und den Frameworks, mit denen man das quasi betreibt.

39:18 Und ob das jetzt Rum ist, ob das Kanban ist oder ob das sowas ist wie ein anderes Framework, das ist aus meiner Sicht nicht das Entscheide. Für mich sind die entscheidenden Dinge tatsächlich die Prinzipien des agilen Manifests, die für mich nach wie vor gültig sind. Und das, was oftmals kritisiert wird an Scrum, ist ja eher so die Art und Weise, wie Scrum quasi die Arbeit organisiert, was für Rollen sie vorsieht, vielleicht wie Scrum, ich sag mal, nach dem Buch gelebt wird.

39:58 Und ich habe viele Umfälle auch kennengelernt, in denen Scrum quasi draufstand. Aber am Ende war es eigentlich nur alter Wein in neuen Schläuchen. Das heißt, die Organisationen haben trotzdem wasserfallartig gearbeitet, haben aber sich den Anstrich gegeben, dass sie nach Scrum arbeiten, haben gewisse Rituale und Zeremonien gehabt, aber die Prinzipien haben sie eigentlich tatsächlich nicht gelebt, die des agilen Manifests.

40:26 Was wird denn an Agilität heute noch am häufigsten falsch verstanden?

40:31 Ist wahrscheinlich auch ein Spektrum, was Leute als falsch verstanden hier sehen, was mir immer wieder begegnet ist, ist, dass ich in meinen Zeiten, als ich Individual Contributor war, Agilität missverstanden wurde, als wir können jederzeit einfach alles anders machen. Wir brauchen eine gewisse Kontinuität in der Art, wie wir arbeiten als Teams.

40:52 Aber ich denke, das, was falsch laufen kann, ist, dass die Rituale wichtiger sind als eigentlich die drunterliegenden Prinzipien. Wesentliche Prinzipien sind für mich eben das iterative, Inkrementelle, dass das, was in Produktion ist, am Ende der echte Beweis ist, dass was funktioniert, wenn es von Kunden genutzt wird und die bestätigen, dass das funktioniert, dass man nicht monatelang an irgendwelchen Funktionalitäten feilt und die dann vielleicht ausrollt, sondern dass diese Inkremente kleiner sind, dass der, ich sag mal, Blastradius für Veränderungen kleiner ist, damit man quasi schneller und souveräner reagieren kann, wenn was nicht funktioniert, das frühzeitig erkennt.

41:37 Also im Grunde sind das sehr stark Validierungsaspekte von Scrum, technisch oder auch, ich sag mal, aus Produktsicht. Die enge Zusammenarbeit mit dem Kunden, die Lernaspekte, dass man das Lernen optimiert, was dann automatisch natürlicherweise dazu führt, dass man gute Produkte baut, Produkte, die den Job erfüllen, den die Kunden erwarten?

42:01 Weißt du, was spannend ist? Wir sind jetzt auch bei der ganzen Sache, wir haben natürlich jetzt über Cloud gesprochen, über Agilität gesprochen, so das Thema DevOps, hast du zwar jetzt genannt, aber ich bin ja auch noch gar nicht so arg drauf eingegangen, weil ich stelle fest, dass DevOps sehr oft auf Tools reduziert wird, auf Pipelines, auf Automatisierung und so weiter.

42:17 Das ist auch ein wichtiger Teil davon. Aber was ist denn aus deiner Sicht der kulturelle oder organisatorische Kern von DevOps, der so wichtig ist?

42:25 Naja, ich denke, für mich tut er sich ganz klar ausprägen in diesem Satz, you build it, you run it. Also es ist Verantwortlichkeit für beide Aspekte, was zu bauen und es zu betreiben. Das ist ganz wesentlich. Und dann die Nähe, das Entfernen von quasi Silos, was im idealsten Fall dazu führt, dass ein Team und die Personen, die da agieren, beständig diese Hüte mehrfach am Tag wechseln zwischen Entwicklungsaufgaben und Betriebsaufgaben.

43:00 Und das führt natürlich dazu, dass Koordinierungskosten reduziert werden, Friktionen reduziert werden, Kommunikations, ich sag mal, die nötig wäre vielleicht, wenn das über mehrere Teams verteilt ist, reduziert wird. Also das sind alles wesentliche Aspekte für mich in DevOps. Und natürlich dieser Automatisierungsaspekt, ja, also den wir vorhin berührt haben, der durch Cloud möglich geworden ist.

43:27 Das heißt, diese Reduzierung der Kosten, Dinge auszurollen und zu verändern. Und die Fähigkeit, beständig Informationen darüber zu bekommen, wie das ganze Setup funktioniert. Also im Sinne von Observability, SLOs, SLIs, SLAs. Und das funktioniert natürlich auch dann nur gut, wenn es da den Schulterschluss gibt, ich sag mal, mit Produkt, ja, was klar artikuliert, was diese Rahmenbedingungen sind, die dann in so einem Setup entscheidend sind, die rechts.

44:00 Realisiert werden, im Sinne von SLAs zum Beispiel.

44:03 Ja, was jetzt viele Unternehmen gerade machen, jetzt ganz aktuell, ist sie ich springe jetzt nochmal zur AI-Adoption, weil das ist die Welt, in der wir jetzt mittlerweile leben, die starten das ganze Thema über Code-Generierung. So, du hast jetzt aber auch gesagt, jetzt auch wieder, Engpass verschiebt sich halt weiter Richtung Validierung.

44:23 Es ist ja auch, you build it, you ship it, you run it, das ist auch ein Teil eines Prinzips. Wo ja, wo zeigt sich denn dann dieses Bottleneck?

44:30 Alles ganz klar. Das zeigt sich, also das eine Generierung ist günstiger geworden, in manchen Unfällen dann vielleicht sogar sehr günstig. Aber auf der anderen Seite ist natürlich wesentlich, dass man validieren kann, dass das, was man baut, dass das technisch funktioniert, dass es gewissen Qualitätsstandards entspricht und andererseits natürlich auch den Wert quasi kreiert, den man braucht, aus einer Produkt, aus einer Kundensicht.

44:57 Also nicht, dass man quasi Outcome verwechselt mit Output. Man kann unheimlich viel bauen, ohne dass man Wert schafft. Das Entscheidende ist eigentlich das Verhältnis, wie viel von dem, was man baut, wie viel Wert schafft es für den Kunden. Und damit ist das die neue Engstelle. Das ist auch bestätigt durch eine ganze Reihe von Studien mittlerweile und ich sag mal Firmen, die quasi CI-CD-Dienstleistungen anbieten.

45:25 Circle CI zum Beispiel hat vor ein paar Monaten eine größere Studie veröffentlicht, wo sie quasi aus ihrem Kunden stammen und dem, was sie da an CICD Arbeit sehen, ganz klar artikuliert haben, Generierung ist nicht das Bottleneck, sondern es ist die Validierung. Und genauso, ich habe einen guten Freund, der bei GitHub arbeitet, die haben das gleiche Problem.

45:48 Die sind überschwemmt worden mit Code, hatten und haben Probleme mit ihrer Stabilität, viel mehr im letzten Jahr als vorher, GitHub. Und das betrifft insbesondere auch die GitHub-Actions-Anteile. Und auch ich persönlich habe das jetzt immer wieder gezogen. Sie kennen mich ausschuldig.

46:05 Ich habe mit Sicherheit dazu beigetragen.

46:07 Genau. Und das ist quasi ein deutliches Zeichen, ja. Das Generieren von Code hat massiv zugenommen, kreiert Skalierungsprobleme und führt zu Validierungsproblemen. Und deswegen halt ist auch für wesentlich, dass wir quasi im Zusammenspiel mit AI artikulieren können, wie die Validierung passiert. Und das sind im einfachsten Fall sind es die Code-Reviews.

46:30 Und jeder, der mit AI, ich sag mal, gearbeitet hat, kennt vielleicht die Situation, dass da, wo er an einem Tag ein PR kreiert hat, plötzlich 20 PRs kreiert, PRs, die dann nicht mehr vielleicht nur 400 Code-Zeilen betreffen, sondern möglicherweise tausende Code-Zeilen über Dutzende Files hinweg. Und die kognitive Last, die sich daraus ergibt, die ist natürlich enorm.

46:50 Weil wenn man den Code selber nicht mehr erstellt hat und dann aber verstehen muss, was da passiert und es bewerten muss, dann ist das eine andere Nummer im Vergleich zu früher.

47:00 Ja, absolut. Wie ist das denn jetzt? Also bevor wir jetzt gleich noch zu den Rapid-Fire-Fragen kommen, wir sind nämlich auch schon fast am Ende, beschäftigt mich jetzt noch die Frage, wir sind mit nachhaltiger Softwareentwicklung gestartet. Und jetzt sind wir in einer Welt, in der AI immer mehr Code produziert und du sagst es selber, Review, Testing, Integration, Deployment, so, das kann vielleicht gar nicht mithalten.

47:21 Was passiert denn dann mit einem Engineering-System und mit nachhaltiger Entwicklung, wenn wir uns jetzt in dieser Situation befinden? Wie stelle ich das denn noch sicher?

47:30 Aus meiner Sicht ist es ganz wesentlich, dass wir ganz wesentlich ist Engineering Excellence, eine wesentliche Zutat, also quasi, dass wir im Sinne von Inner- und Outer Loop, also Inner-Loop betrifft so Dinge wie der Entwickler quasi mit der AI am Code arbeitet, dass wir da Qualitätsstandards artikulieren im Sinne von Linting, Style Guides, im Sinne von Qualitätsstandards, Code-Qualitätsstandards, wie zum Beispiel zyklomatische Komplexität, dass wir Tooling haben, was Sicherheit sicherstellt.

48:05 Das kann alles im Innerloop passieren und das kann aber auch im Outer Loop, also in der CICD-Pipeline, selbst als zweites Sicherungsnetz passieren. Und ich denke, das ist ganz wesentlich. Wenn wir quasi wenig Reife haben in der Art und Weise, wie wir diesen Code produzieren, wie wir das System entwickeln, dann wird die durch AI nur verstärkt.

48:25 Und wenn wir aber umgedreht quasi ein hohes Maß an Engineering-Qualität haben in diesem Prozess, dann wird das durch die AI verstärkt. Also es bewegt sich in beide Richtungen, dieser Verstärkungseffekt.

48:36 Sehr gut nachvollziehbar und das sehe ich tatsächlich auch. Govinda, wir sind tatsächlich, die Zeit ist uns auch davon gerannt. Wir haben sogar noch eigentlich viel mehr Themen noch auf der Bliste gehabt, wie wir es am Ende geschafft haben. Aber die Rapid-Fire-Fragen, die lassen wir uns nicht entgehen.

48:52 Dafür müssen wir uns noch Zeit nehmen. Was ist denn der größte Mythos über technische Schulden?

48:57 Dass es ein rein technisches Problem ist. Aus meiner Sicht sind es oft Geschäftsentscheidungen. Und der zweite Mythos damit ist, dass Schulden immer schlecht sind. Bewusst eingegangene Schulden, geplante Schulden sind ein legitimes Werkzeug. Gefährlich ist nur die leichtsinnige Variante, die man unsichtbar anhäuft und die man nicht dann wieder abträgt.

49:18 Bewusst.

49:19 Das unterstütze ich sehr, was du da sagst und das trifft den Nagel auf den Kopf. Die am meisten unterschätzte Fähigkeit eines CTOs.

49:26 Übersetzung. Die quasi Übersetzung zwischen Penthouse, Sea-Level, Board und dem Maschinenraum. Und quasi in beide Richtungen und dieser ständige Wechsel, also quasi mit all den Ebenen, die dazwischen sich befinden und den unterschiedlichen Abstraktionsebenen und Details.

49:46 Ich glaube, wenn du im richtigen Unternehmen bist, dann sitzen auch die Engineers im Penthouse. Frag mal bei OpenAI nach. Ein Architekturprinzip, das fast immer hilft.

49:56 Lose Kopplung und klare Grenzen. Also saubere Bounded Contexts und Team-RPs. Ein bisschen verbunden mit den Domain-Driven Design-Aspekten, über die wir vorher gesprochen haben.

50:08 Sehr gut.

50:09 Und dann noch eine Faustregel, bau für das Zehnfache, nicht für das Hundertfache. You ain't gonna need it.

50:15 Richtig, richtig. Das ist richtig. Auch eine Frage, die mir sehr gefällt und ich bin auf deine Antwort sehr gespannt. Cloud, DevOps und Agilität in einem Satz.

50:25 Drei ermögliche für ein und dieselbe Sache. Schnelle Feedback Loops mit echtem Ownership.

50:30 Oh, schön gelöst. Sehr gelöst, finde ich sehr gut. Letzte Frage für heute, Govinda. Die erste Frage, die ein CTO stellen sollte, bevor AI-Coding-Tools wirklich breit ausgerollt werden.

50:42 Würden unsere Tests, unser Review und unser Observability-Harness heute einen schlechten Change zuverlässig abfangen? Wenn die Antwort Nein ist, dann ist das nicht die eigentliche Baustelle, nicht das Tool.

50:54 Ja, dann musst du eher wieder an den Review-Prozess ran und musst dann gucken, wie du denen absicherst, oder?

50:58 Engineering Excellence und all die Prinzipien, die da drin realisiert sind, ja.

51:02 Sehr gut. Govinda, wir haben heute eine schöne Reise, sind wir angetreten, von technischen Schulden über nachhaltige Softwareentwicklung. Wir haben das Thema Cloud, wir haben das Thema DevOps mit drin gehabt und so weiter. Wir haben auch über Agilität gesprochen und am Ende natürlich auch noch sind wir bei AI angelangt.

51:18 So, und haben dann nochmal den schönen Bogen geschlagen. Vielen Dank für deine Insights. Ich glaube, das hat auch nochmal das sehr gut geholfen einzuordnen. Und das ist durchaus noch genauso relevant im Jahr 2026. Das darf man nicht vergessen, auch wenn da ganz viel Software da draußen gerade gebaut wird, wie blöde, dass es immer noch die Notwendigkeit gibt, einen nachhaltigen Softwareentwicklungsprozess zu haben.

51:41 Vielen Dank für deine Insights und vielleicht kommst du dann nochmal zu mir in den Podcast und dann holen wir noch die anderen Fragen oder anderen Themengebiete. Das sind so ganze Themengebiete, die wir ausgelassen haben, die holen wir danach.

51:50 Das wäre wunderbar. Super. Vielen Dank für das tolle Gespräch.

51:53 Danke, Govinda. Mach's gut. Bis dann. Ciao, ciao.

51:55 Ciao.