Ja, sehr schön. Du bist einer der Ersten, jetzt nicht geantwortet haben. Irgendwas mit AI? Das ist spannend. Also wirklich dein eigenes Open Source Projekt. Wir werden das in den Show Notes verlinken. Und danke dir dafür. Wie bist du eigentlich zu der Technologie gekommen? Was hat bei dir diesen Funken ausgelöst, dass du wusstest, da möchte ich arbeiten? Und da finde ich quasi das, was mich ausmacht.

Ich hör zu der Generation, in der diese Heimcomputer spannend waren. Ich hab mich damit bisschen beschäftigt, fand die ganz faszinierend, was zumindest dann dazu geführt hat, dass ich so weit interessiert war, dass ich Informatik studieren wollte, was ich dann auch getan hab. Und da ist mir klar geworden, während des Informatikstudiums, dass auf der einen Seite mich die Technologie, die Computer interessiert haben, aber die reine Theorie irgendwie auch nicht genug war, sondern dass mich immer interessiert hat, was kann man mit der Technologie eigentlich machen? Was ist das Potential davon? Ich hab das Studium beendet, aber mich dann offensichtlich

für die Wirtschaft entschieden und viel, ich hoffe zumindest, viel Gutes mit Software erreicht.

Ja, genau da werden wir jetzt auch noch mal mit einem Doppelklick drauf machen und tiefer reingehen. In deiner Rolle bei ThoughtWorks und über die Zeit habt ihr natürlich einiges auch mit verändert und geprägt. Also du warst bei der ersten oder einiger bei der letzten großen Disruption mit dabei, wo wir quasi von der klassischen Entwicklung

in eine agilere Softwareentwicklung oder mit agilen Methoden gestartet sind. Du hast CI-CD gemacht, bevor es das Wort gab. Ihr habt das Thema Microservices mitgeprägt. Wir haben im Vorgespräch über so etwas wie Phoenix Server gesprochen. Nimm uns mal mit auf der Reise und erzähl mal, wo ihr dort oder du persönlich auch Akzente gesetzt habt.

Ich will sagen, das CI-CD, können wir sofort drüber sprechen. Es fängt sogar noch einen Tacken früher an. Also ich habe 2002 bei ThoughtWorks angefangen, in London damals. Und es gab da den Extreme Tuesday Club. Das war eigentlich eine lose Versammlung von Leuten, nichts Formales, die sich in einem Pub tatsächlich getroffen haben, wo viel darüber diskutiert wurde, wie man Softwareentwicklung besser machen konnte. Und irgendwie war zu dem Zeitpunkt die Idee, wie man Tests besser machen könnte, relativ zentral. Also TDD, Test for Development, war schon im Gespräch, aber es fehlte halt noch viel

Die Theorie war allen klar und JUnit, diese Frameworks, die gab aber wie man das dann skaliert über einen großen Bereich hinweg und wie man es genau an welche Designmuster da benutzt werden können und welche sinnvoll sind zu benutzen, das war eine ziemliche Diskussion und es ging dann damals ein bisschen hin und her. Im Nachhinein wurde das dann auch Chicago School und London School of Testing genannt. Es ging so ein bisschen darum, wie mock objects benutzt werden. Die Leute, die die Original Paper geschrieben haben, haben auch zu der gleichen Zeit bei Thoughtworks gearbeitet und waren auch dabei.

Das war für mich interessant zu sehen, dass die Diskussion gar nicht mehr war, macht man TDD oder nicht, wie macht man das eigentlich besser. Das war erfrischend zu sehen, dass wir uns darauf fokussieren konnten, das, was wir gesehen hatten, was sehr erfolgsversprechend war, weiter zu versuchen, verbessern. Anstatt immer wieder nur zu diskutieren, ist es das Richtige, ist es das Falsche, welche Bedenken hat man, sondern einfach wirklich nach vorne zu gucken. Du hattest die CI/CD angesprochen. Das war tatsächlich ein...

ein gutes Stück später, ein paar Jahre später. Continuous Integration war schon ein existierendes Konzept. weiß nicht, wie bekannt das überhaupt ist. ThoughtWorks hatte damals den allerersten weltweit überhaupt den ersten existierenden CI-Server programmiert. Der hieß Cruise Control oder der heißt Cruise Control. Man kann ihn immer noch in den einschlägigen, ich glaube auf SourceForge tatsächlich finden. Oder auf jeden Fall, wenn man danach sucht, kann man das noch finden. Würde man heute natürlich nicht mehr benutzen. Aber diese Idee, dass eine Software auf einem Source Control Repository schaut,

bemerkt, wenn neue Check-ins gemacht worden sind, den Code baut und danach eine Test-Street ausführen. Das gab es damals schon. Und jetzt komme ich auf die eigentliche Frage zurück, der Beitrag von ThoughtWorks, auch mein persönlicher Beitrag war, war eben zu sagen, wie kann man das weiterführen? Für mich persönlich war das beim Guardian. Der Guardian ist eine große englische Zeitung. Ich glaube, die ist inzwischen auch in Deutschland einigermaßen bekannt. Die hatten sich damals entschieden,

von einem Content-Management-System wegzugehen, um eigene Software zu schreiben, weil ihnen sehr, sehr früh klar war, dass die Webseite die Zeitung sein wird. die haben damals schon, wir sprechen jetzt hier 2005, 2006, die haben damals schon gesagt, wir gehen eigentlich von der Zeit aus, von der Planung aus, wo die Zeitung nur noch die ausgedruckte Webseite ist und nicht anders, wo im Artikel aus dem Zeitungssystem irgendwie auf die Webseite gepusht werden. Das wollten die bauen. Was für den Guardian extrem wichtig war, natürlich die, wie sagt man das auf Deutsch?

dass die Webseite schnell und immer verfügbar war. Aber gleichzeitig wollten die auch viele neue Sachen ausprobieren. So Tags und Keywords. Es war natürlich auch damals schon wichtig, dass die Leute lange auf der Webseite bleiben. Auch eine Zeitung wie der Guardian ist zumindest zum gewissen Teil werbefinanziert. Das heißt, man wollte gucken, dass wenn Leute vielleicht auf einen Artikel gekommen sind. Wir haben damals auch schon festgestellt, dass ein Großteil des Traffics durch organische Suchen waren. Also auf die Artikelseiten kamen und dann haben geguckt, wie kommen wir auf die nächste Seite.

Also wie kriegt man die Leute dazu oder wie kann man den Leuten Inhalte anbieten, die für sie spannend sind, dass sie von der einen Seite auf die nächste gehen. Und von dem Hintergrund hatte man also auf der einen Seite den Wunsch, dass die Webseite möglichst schnell ist. jeden Fall aus, weil sicher auch bei großen Events, wie wir haben damals auch viele Sport-Events, das war am Anfang noch ein viel größeres Problem, Sport-Events gehabt, wo die Leute wirklich im Browser dauernd Refresh gedrückt haben, zu sehen, hat sich das Ergebnis von einem, also gerade Experts

hat sich das Fußballergebnis geändert und so weiter. war wichtig. Und auf der anderen Seite aber auch die Komplexität. Und an der Stelle haben wir dann angefangen, nur funktionale Tests zu machen, also test-driven development, wir haben dann auch angefangen mit Tools wie Selenium, damals gab es noch ein paar andere Tools, automatisierte Click-Tests zu machen. Aber was auch da an der Stelle immens wichtig war, war Last-Tests zu fahren. Also vollautomatisierte Last-Tests. Bis hin zu dem Punkt, wo man einfach gesagt hat, wir müssen auch, wir haben das in Java programmiert damals, aber auch in Java kann man Memory Leaks bauen, also das geht.

Es wurde mehrfach eindrucksvoll bewiesen. Und so dass wir dann auch bei Code-Änderungen immer Last-Tests laufen lassen wollten, die auch mal 24 Stunden durchlaufen und wirklich bei maximaler Load arbeiten. Und da war natürlich das Konzept von Continuous Integration am Ende, würde ich mal sagen. Also die Idee, dass ein CI-Server sieht, hier wurde Code eingecheckt und ich lasse einfach mal alle Tests laufen, das konnte an der Stelle nicht mehr funktionieren, weil es einfach zu viele, unterschiedliche Tests waren, sodass wir uns da dann, das hat da keiner damals so genannt,

aber konzeptionell eigentlich schon an diese Idee von einer Testpyramide herangearbeitet haben. Und dann haben gesehen, okay, müssen die Unit-Tests, die müssen ganz schnell laufen, wir diesen Effekt bekommen, dass wenn ein Code eingecheckt wird und dieses It works on my machine, aber läuft nicht auf dem Server, dass dieser Effekt möglichst schnell, dass das Feedback möglichst schnell in die Entwickler geht, aber wir gleichzeitig auch die Möglichkeit haben, vollautomatisiert einen 24-stündigen Lasttest laufen zu lassen.

Und dann haben wir tatsächlich mit den Tools, wir hatten, das waren alles im Prinzip Shell-Skripte, haben wir angefangen, diese verschiedenen Testläufe aneinander zu hängen. Und es war wirklich ein bisschen hässlich, wie wir das gemacht haben. Aber im Endeffekt war es genau das. Es war genau eine Build-Pipeline, die mehrere Stufen hatte. Wir haben das am Anfang, ich weiß nicht, ob man es im Internet finden kann. Also am Anfang haben wir das noch CI++ genannt, so ein bisschen wie C++ und C, also CI Continuous Integration++, bis dann später.

Jess Humble und Dave Farley, die auch zu dem Zeitpunkt bei ThoughtWorks in England gearbeitet haben, dann das Buch geschrieben haben und sich dann den Begriff Continuous Delivery aus den Seiten hinter dem Angivel-Manifest rausgesucht haben und dann dem Ganzen ein deutlich besseres Wort gegeben haben. Auch ein Wort, was viel besser beschrieben hat, worum es eigentlich geht. Nicht nur was man tut, Continuous Integration, sondern worum es geht, dass man kontinuierlich liefern kann. Immer Working Soft.

sehr eindrucksvoll. Was ich jetzt bei dir rausgehört habe, du hast gemeint, das waren einfach so paar Skripte hintereinander. Ich relativiere jetzt mal, war mit Sicherheit eine hochkomplexe Technologie auch dann, die ihr dort aufgebaut habt. Aber was man raus hört, ist es nicht nur die Technologie, also es ist mehr auch wie wir arbeiten. Also es hat sich dann verändert, die Art und Weise haben

Deine Kollegen dort mit dir auch schon in Richtung DevOps gedacht, dass wir übergreifende Verantwortung hatten für, gerade wenn es darum geht, die Seite muss immer verfügbar sein, weil damit hat man dann irgendwann den Disconnect zwischen Betrieb und Operations gehabt. Seid ihr da schon in die Richtung gegangen von der Teamaufstellung oder war das noch rein alles getrennt?

Ja, es gut, dass du das ansprichst. Ich glaube, das ist sogar ...

Das war eine Voraussetzung irgendwie, dass das uns bewusst war. Ich will jetzt auch nochmal sagen, also der Guardian, wo ich jetzt war, ich war der Tech Lead damals, war nicht das einzige Projekt. Wir haben das bei einigen anderen Kunden auch gemacht und haben uns natürlich intern auch abgesprochen und bisschen verglichen und teilweise auch die Ideen für die Skripten und so weiter ausgetauscht. Also es war nicht nur das eine Projekt, bei vielen und beim Guardian weiß ich es natürlich aus eigener Erfahrung, war es mit Sicherheit die Idee von dem, nicht wirklich was wir DevOps nennen, aber dieses enge Zusammenrücken von Betrieb.

und Softwareentwicklung. Ich hatte es ja gesagt, der Guardian hatte ein Content Management System, das heißt, die hatten gar keine großartige Software Development Kapazität im Haus. Also die hatten gar nicht so viele Leute, die Software entwickeln konnten und schon gar nicht in der Technologie, zu der wir geraten haben und die dann auch genommen worden ist. Nämlich ja, weil die hatten vorher das in, falls das noch einer kennt, TCL, weil das ursprünglich mal auf dem Vignette Story Server CMS lief. Also die hatten ganz andere Erfahrungen.

Wir, die wir eingekommen sind, hatten überhaupt keine Erfahrung darin, wie die Software gehostet wurde. Und was sie damals wirklich gemacht haben, die haben genau, ich glaube intuitiv, irgendwie viele von den Ideen vorbeigekommen auch, die haben uns zusammen auf eine Etage gesetzt. Also wir saßen da in London, das war damals noch in Farringdon, wir haben auf einer Etage zusammengesessen mit den Betriebsleuten, die beim Guardian Fest angestellt waren. Mit einem kleinen Thoughtworks Team, anfänglich zumindest, das ist größer geworden, und einer kleinen Gruppe von

Leute, die Software entwickelt haben, die schon beim Guardian gearbeitet haben. diese Leute, dadurch haben wir so einen Business-Austausch gemacht, auch genau, was wir auch hatten. Wir hatten Vollzeit einen von den Domain-Ownern, man sagen, einen wirklichen Editor. Wie heißt das auf Deutsch? Also jemand, für die Zeitungsartikel verantwortlich ist und Redakteur, Entschuldigung, genau. Ein Redakteur, abgestellt war für das Projekt. Und wir saßen wirklich alle zusammen auf dieser einen Etage in dem Headquarter vom Guardian oben. Die Leute vom Guardian haben das Domänen-Wissen gebracht. Wir haben

Die Idee gebraucht, wie man Softwarearchitektur macht, man Routesoftware baut und die Leute vom Betrieb saßen direkt neben uns. Und genau diese Sachen, das waren die waren es, glaube ich, auch, wenn ich mich richtig erinnere, gesagt haben, ihr müsst diese Last-Tests machen. Das ist mir egal. Wenn ihr da zehn Requests macht und timet, dass die so viele Millisekunden brauchen. Ich will sehen, was passiert, wenn da auf einmal hunderttausende von Requests auftauchen. Und man darf das nicht vergessen. Es war damals ein fester Pool an Servern. Das war kein Cloud Computing. Das war ein fester Pool an Servern, die geleast waren und möglichst nah

an irgendwelchen Internet Exchange Quoten standen, um die Latenzzeit zu verringern. Und genau was du sagst, ich glaube, ist, ich will nicht sagen, man hat DevOps vorweggenommen. Ich glaube, das war einfach so eine Entwicklung, die zu dem Zeitpunkt stattgefunden hat, die dann hinterher durch DevOps einen Namen bekommen hat. Aber genau dieses, also meine Erfahrung, ich war bei den zweiten DevOps-Days, nicht bei den allerersten, aber bei den zweiten, das fühlte sich stark nach so einer Grassroots-Bewegung an. Wir saßen in einem Raum, mit 50 Leuten oder so.

Und es waren alles Practitionals, alle Leute, gearbeitet haben und sagten, wir können nicht mehr arbeiten, ohne miteinander zu reden. Wir können nicht mehr sagen, ich bin Betriebler, bin Entwickler. Wir arbeiten bei verschiedenen Firmen und feinden uns an. Wir müssen zusammenarbeiten. Ich glaube, ist eben das, was aber vielleicht durch Glück, durch Zufall beim Guardian oder anderen Kunden entstanden ist, dass die Leute einfach zufällig zusammensaßen. Und das Guardian hat natürlich ergeben, dass man so gearbeitet hat.

Das war super spannend.

Ja, echt spannend. Man sagt ja oft, DevOps ist keine Technologie, sondern ein Mindset. Also das heißt, dass man bei den Menschen das richtige Mindset braucht. Aber der Guardian war ja auch eine große Firma. Und da gibt es natürlich Regeln und Prozesse. Wie habt ihr das geschafft, dass ihr gesagt habt, wir nehmen jetzt hier die Abteilung, setzen alle mal in einen Raum. War das schwierig oder hat sich das einfach gefügt aus der Not, wir müssen jetzt liefern?

Ich würde mal sagen, weder noch. Ich kann da gar nichts zu sagen. Wir haben da keinen Anzahl dran gehabt. Das hatte jemand so entschieden. Das war ein Ausschreibungsverfahren für uns. Wir mussten einen RFP, Request for Proposal, ausfüllen. Haben uns wirklich Mühe gegeben, weil wir den Guardian als Kunden gerne gewinnen wollten. Und die Art und Weise, wie wir da zusammengesessen haben, das war tatsächlich schon im Vorfeld von den Leuten am Guardian so entschieden worden. Wäre mal spannend zu wissen. Ich habe da noch nie darüber nachgedacht, ob die das aus einer Note heraus gemacht haben. Ich glaube nicht. Ich glaube, die waren schon...

so, dass sie gesagt haben, wenn wir das jetzt schon machen und wenn wir sagen, dass die Software unsere Zeitung ist, diese Website ist unsere Zeitung, dann wollen wir auch die Leute, die daran arbeiten, zusammensetzen. Ich glaube, das fühlt, jetzt wo ich auch nochmal über nachdenke, ich habe die Geschichte schon mehrmals erzählt, aber die Nuance habe ich noch nicht betrachtet. Es war einfach so eine kollaborative Herangehensweise, die der ganzen Sache zugrunde lag und ich glaube deswegen

fühlt sich das richtig an, war aber nicht jetzt von uns eine Empfehlung, dass wir gesagt haben, also wenn wir das machen, dann müssen wir unbedingt mit den Betriebsleuten zusammensitzen. Es war eher, dass wir gesagt haben, wir würden euch gerne helfen, diese Webseite zu bauen. Und dann haben gesagt, okay, da sind eure Plätze und übrigens nebenan sitzen die Leute vom Betrieb.

Ja, sehr cool. Vielleicht einfach intuitiv schon richtig alle Leute, die wir brauchen, in einen Raum gesteckt. Wenn man jetzt ein bisschen die Zeit vorantritt, also ganz viele Themen sind natürlich dort Infrastructure as Code, einfach wieder herstellbare Builds auf Knopfdruck zu erhalten. Das sind ja alles Praktiken, die mittlerweile State of the Art sind, die

je nach Journey des einzelnen Unternehmens quasi mehr oder weniger etabliert sind, aber schon zu den Praktiken gelten, wie man Cloud Native entwickelt. Und was damit oft passiert, ist, baut man eine Industrie aus. Also ist ein Haufen Geld auch drin, es wird Tooling bereitgestellt und es kommt dadurch auch eine hohe Komplexität rein. Nimmst das ähnlich wahr? Also wie hat sich das verändert von ein paar Bash-Skripten hin zu

Cloud Workload, jetzt irgendwie eingekauft werden, ganz viele Anbieter, die es gibt und haben wir dann noch diese kurze Responsezeit, die wir wirklich brauchen. Wie siehst du das, wie war es zu dem Markt?

Also ich glaube, mit Fehlerhin sich dieses besser geworden, weil die Tools einfach ausgereifter, ausgefeilter sind. Natürlich hat man irgendwann auch den Effekt, du gerade schon angedeutet hast, dass natürlich dann ein Riesenmarkt da ist und dass die verschiedenen Tools miteinander konkurrieren, indem sie immer mehr Nischen, immer mehr komplexe Funktionalität haben. Aber die Basisfunktionalität ist ja an vielen Stellen gegeben und ich denke mal, so was wie Kubernetes, wenn das vor 10, 15 Jahren schon in der Reife da gewesen wäre, hätten die Leute sich mit Sicherheit drauf.

Man hätte viele Sachen nicht selbst gemacht. weiß, haben hier bei einem Kunden, als ich dann in Deutschland war, relativ früh, das muss 2014, 2015 gewesen sein, die ersten Lösungen auf AWS gebaut und haben die Deploymentskripten selbst bauen müssen. Also es gab halt kein Terraform. wollten, der Kief Morris, der das Buch geschrieben hat, übrigens der war bei dem Kunden auch beteiligt und wir haben da auch, ich war auch bei dem Projekt beteiligt.

Und wir haben teilweise auch nebeneinander gesessen. Ich erinnere mich noch, Kief irgendwann mal sagte, das muss irgendwer mal aufschreiben. Und einige Leute haben mich eingeschlossen und schreib du doch das Buch. Hat er dann auch gemacht, glücklicherweise. ich will schon sagen, ich glaube, die Tools im Großen und Ganzen sind deutlich besser geworden. Es ist eine große Erleichterung. Es ist besser, versuchen, das selbst zusammenzustricken. Wie gesagt, der einzige Nachteil, aber das kann man keinem wirklich vorwerfen, natürlich, dass die Tools dann immer noch ein Feature mehr und noch ein Feature mehr haben, wo man dann irgendwann sich wirklich ein bisschen...

konzentrieren mussten sagen, was will ich denn hier eigentlich wirklich bauen und wie kann ich alle Features ausnutzen oder so ein bisschen den, dass man den Wald für lauter Bäume nicht sieht, aber es ist auf jeden Fall besser diese Tools zu nutzen als das selber zu stricken, das würde ich keinem empfehlen.

Ja.

Ja, sehr gut. Was man aber nicht wegdiskutieren kann, ist, eine Riesenkomplexität quasi auf diese Teams, die jetzt cross- funktional unterwegs sind, einbrischt Wie handelt man diese Komplexität am besten? Was sind da deine Geheimrezepte oder was siehst du oder hast du gesehen bei deinen Kunden auch oder bei irgendeinem Kunden?

Also da würde ich einfach sagen, die beste Art und Weise damit umzugehen ist beschrieben worden in dem Team Topologies Buch. Also einfach zu gucken, dass man verschiedene Teams hat, die, was ich rund heraus ablehnen würde, ist diese Idee von einem Full-Stack- oder Full-Spectrum-Developer, weil es irgendwann einfach, es gibt vielleicht irgendwelche Superhelden, aber in der Regel findet man niemanden, der im neuesten JavaScript-Framework alle Details kennt und aber auch genau weiß, wie bestimmte

Maschinentypen von AWS sich in der Cloud verhalten. Es ist einfach ein zu großes Wissensfeld inzwischen, sodass man hier eigentlich schon ein ganzes Team braucht, mindestens, wo verschiedene Skills drin sind, damit man eben Businesswert liefern kann. Und das war auch eine gewisse Zeit lang, ich würde mal sagen, der Default Ansatz zu sagen, wir haben diese, ich sag mal zwischen 10 und 20 Leuten, eine Größe, die man noch gut verwalten kann, die sich ⁓ eine bestimmte

Funktionalität kümmern, also im E-Commerce Bereich kann man das mal gut sagen. So was wie eine Artikel-Detailseite wird halt von einem Team programmiert Ende zu Ende, also von dem HTML bis zum Deployment in die Cloud und dieser könnten und sollten dann auch in der Lage sein, Änderungen, die sie an ihrem Code machen, unabhängig zu deployen. Und deswegen, nochmal auf das Team Topologies zurückzukommen.

Ist es aber irgendwann doch, und da haben wir uns auch lange drüber unterhalten, ich sage jetzt wir bei ThoughtWorks, lange drüber unterhalten, aber auch mit unseren Kunden und Kundinnen, ab welcher Größe funktioniert dieses System eigentlich nicht mehr? Ab welcher Größe kann ich nicht einfach nur sagen, ich habe diese 10 bis 20 Leute Teams und irgendwer macht den Domäne-Schnitt und macht den richtig, dann wird auch immer gerne über bounded-Kontext gesprochen. Und die Annahme ist, dass man es sofort richtig macht. Wenn man mehr Erfahrung hat, dann merkt man, dass man das eigentlich nie sofort richtig hinkriegt und schon Mechanismus einbauen.

einbauen muss, zu gucken, dass man sich hinterher noch mal korrigieren und nachstellen kann. Aber wo kommt der Punkt, wo man nicht einfach nur ein Team neben Team neben Team neben Team setzen kann? Und ich würde sagen, es gibt natürlich keine abschließende Antwort, aber meine persönliche Faustregel ist so 80 Leute oder so. Und ab da müsste man anfangen, sich neue Gedanken zu machen in dem Modell, was als Spotify Modell bekannt geworden ist. Gibt es hier diese Unterscheidung zwischen Squads und Tribes dann. Aber an den meisten Stellen würde ich sagen,

bei der, wenn der Fokus ist, und das ist normalerweise eine gute Idee, Software schnell und unabhängig zu deployen, ist ein erster guter Schritt, immer ein Plattformteam aufzubauen, die eine Plattform bereitstellen, weil man da wirklich viel Komplexität aus den Teams rausnehmen kann und man, so gerade mit den modernen, inzwischen ist es ja auch schon Standard natürlich, aber sowas wie Docker und Kubernetes hat man eine sehr, gute Abstraktionsebene, wo sich ein Plattformteam darum kümmern kann, das bereitzustellen.

und die Teams einfach wirklich nur noch Container liefern müssen und somit schon einen guten Teil der Komplexität wegnehmen.

Das heißt, sie sind dann einfach für die Businesslogik, also einfach in Anführungszeichen zuständig und Infrastruktur und das, wo es läuft und wie es laufen muss, wird dann unterstützt durch ein Plattformteam. Was für mich...

Invalid.

Auf der anderen Seite, das wird immer gerne vergessen, aber für mich ist es eigentlich genauso wichtig. Wir sprechen ganz, viel über DevOps. Wir sprechen viel über Programmieren und Programmiersprachen und Betrieb. Was aber aus meiner Erfahrung nach genauso wichtig ist, weil nicht in der Breite behandelt wird, ist das User Experience Design. Also das ist, wir haben das auch schmerzhaft erlebt. Du hattest ja gefragt, so DevOps und was waren die frühen Ansätze, aber wir haben relativ früh auch gemerkt, dass das nur die eine Hälfte war. Also ich hatte das auch mal in

Konferenzvorträgen gezeigt, so eine Person, in so einem Hamsterrad läuft, dass wir gesagt haben, diese kleinen Teams, die TDD machen und schnell liefern und immer schnell Software durch eine CI-Pipeline laufen lassen können, die bereit ist, mit bestem Wissen und Gewissen deploit zu werden, aber da nicht deploit wurde, weil eben diese große Lücke, die große Mauer war zwischen Betrieb und Entwicklung. Aber auf anderen Seite hatten wir genau das gleiche Problem, die Benutzeranforderungen, die Anforderungen der Nutzer, die zu organisieren.

war eben auch nicht einfach möglich, wie wir es anfangs vielleicht naiv geglaubt haben, man einfach Leute, die Softwareentwicklung können, neben die Leute setzen, die das System benutzen. Also bei einem B2C vielleicht hat man dann noch eine gewisse Affinität zu der Domäne, aber gerade wenn es im B2B-Bereich ist und interne Anwendung, kann sich da nicht einfach nur nebeneinandersetzen. Es hat natürlich an einigen Stellen funktioniert, wenn ich mit Martin Fowler darüber spreche, dieses Chrysler-Projekt und so.

In der Breite hat es halt auch nicht funktioniert. Und das, dann da unglaublich wichtig war, war genauso, wie man diese Verbindung geschaffen hat zwischen dem Softwareentwicklungsteam und den Betriebsleuten, eine gleiche Verbindung auf der anderen Seite sozusagen zu treffen, zwischen den User Experience Designern oder Custom Experience Designern. hießen, also ich meine jetzt nicht nur Grafikdesigner, ich meine eben auch Leute, die User Research machen können, die verstehen, was gebaut werden soll. Manchmal werden die Business Analysts genannt, heute heißen die Rollen auf Product Owner und so weiter.

dass das da genauso funktionieren kann und so ähnlich, wie wir das mit Abstraktionen und Technologie gesehen haben, wie eben so was wie Docker und Kubernetes, sehen wir jetzt auf der anderen Seite sozusagen auch so was mit Design Systems, gebaut worden sind, mit Tools wie Figma und den Möglichkeiten, wie da Exporte gemacht werden können, die direkt benutzt werden können und so. Also ich will schon sagen, dass beide Seiten aus meiner Sicht gleich wichtig sind, obwohl in der Debatte im IT Bereich vielleicht weil Betrieb ein bisschen technisch ist, ich weiß nicht.

einen größeren Stellenwert einnimmt. Aber ich glaube, man das andere vernachlässigt, hat man auch oft genauso große Probleme.

Das ist spannender Trade-off sozusagen auch, weil wir wollen ja auf der einen Seite die Teams eine schnelle Bewegung halten. Also sie sollen unabhängig auch entscheiden und auch Features implementieren. Aber auf der anderen Seite haben wir das Gesamt User Experience. Also wenn ich jetzt auf so eine eBay Seite gehe oder auf einer Amazon Webseite, dann will ich natürlich durchgängig das Gefühl haben, ich habe eine Seite und ich habe nicht lokal optimierte kleine Komponenten, die für sich stehen. Und das diese Gesamtstrategie, den Gesamtproduktansatz in diese einzelnen Teams auch reinzukommunizieren.

ohne dass ich die aufhalte, ohne dass ich sage, hey, stopp, brauchen jetzt ein Planning, hier müssen alle Teams drin sein, das ist die nächste Richtung, wir gehen. Also das ist bestimmt eine große Herausforderung immer noch heute, oder?

Ja, mit Sicherheit. Aber wir sind also auf der einen Seite helfen eben Techniken, nicht Technologien, also Techniken, Praktiken, wie gearbeitet wird, aber eben auch Technologien und Tools, das schon besser zu machen. Ich habe von Design Systems gesprochen und von solchen Tools, die das schon verbessern können, dass die Teams ohne großen Aufwand, sage ich jetzt mal, mit wenig Komplexität eben eine Lösung bauen können, die, wie du sagst, in Deutschland nehmen wir sie, die fühlt sich an wie aus einem Guss und so weiter, also dass das schon eher so hinhaut.

Ja, echt interessant. Ich glaube, das ist wirklich eine spannende Herausforderung, wo wir eine Agilität skalieren müssen. Wir sehen jetzt im Moment eine neue Disruption, die auf die Softwareentwicklung zukommt. Und in allen Medien, in allen Talks, wie auch immer, Thema AI ist präsent. Also wie nimmst du das Thema AI wahr? Und wann hilft das uns? Und wie setzen wir es am besten gewinnbringend ein im Softwareentwicklungs?

Zyklus.

Nur zu sicher, wenn wir jetzt AI sagen, meinen wir generative AI. Weil AI als solche Machine Learning natürlich alte Technologien sind. Seit den 60er Jahren spricht man über KI. Aber wo wir jetzt drüber sprechen, ist generative AI.

einigen Leuten oder vielen Leuten wahrscheinlich relativ schnell klar war, ist das einfach überraschend war, überraschend in der Art und Weise, wie es passieren konnte. Man kann das nachlesen. Wir haben bei ThoughtWorks, oder wir bringen bei ThoughtWorks, einen Technologierader raus, zweimal im Jahr. Und wir haben tatsächlich schon lange bevor ChetGBT rauskam, diese Transformer-Technologien und Pre-trained-Technologien auf dem Techradar erwähnt. Das heißt, es war uns bekannt,

Und wenn man sich dieses Paper die ganze Geschichte Timnit Gebru bei Google und so weiter, das ist ja auch einige Jahre davor gewesen. Das heißt, es schwebte schon so bisschen und es war klar, hier ist irgendwas überraschend Gutes. Wir müssen noch gucken, was wir damit tun können. Und was dann aber interessanterweise passiert, ist, ist relativ schnell, weil es natürlich eine Software-Technologie ist, sich das in so zwei Bereiche gespalten hat. Einmal diese ganze, wie kann man Genitive AI für Business-Probleme einsetzen?

Und das andere, wie kann man Genotive AI dafür einsetzen, Software zu programmieren? Natürlich auf einer abstrakten Ebene ist Software programmieren auch ein Business Problem. Aber ich glaube, das ist schon in zwei verschiedene Richtungen Ich habe eine Menge Lösungen gesehen, wo Genotive AI ein hilfreiches Mittel war. Also wo eine Lösung über eine, die man öffentlich reden kann. Also da gibt es auch auf der ThoughtWorks Webseite Case Studies zu. Wir haben für einen großen Pharmakonzern, für die Leute, die lieben

Forschungsbereich sind im Preclinical Trial Bereich ein System geschrieben, was einfach Retrieval Augmented Generation benutzt, was den Forschenden ermöglicht, die ganzen internen Studien und die Daten viel besser zu finden, ⁓ die Forschung schneller voranzutreiben und mit weniger Aufwand zu machen. Und das ist ja nur ein Beispiel. Es gibt ganz, ganz viele davon. Aber ich glaube, da wird auch, es gibt eine unglaubliche, es gibt so ein Spannungsfeld, das würde ich jetzt mit meiner CTO-Mütze mit so aussagen.

die ich bei den Kunden wahrgenommen habe. Auf der einen Seite gibt es FOMO, also dieses Fear of Missing Out, weil, wie du gesagt hast, Felix, ist natürlich überall, alle sprechen davon und man überbietet sich damit, sagen, wie viel besser und wie viel schneller man geworden ist. Und bei ganz vielen Unternehmen ist dann vielleicht so ein Selbstzweifel da drin und wenn es im eigenen Unternehmen nicht so gut geklappt hat, dann will man nicht darüber reden, weil man denkt, alle anderen haben ja Erfolge gefeiert und wenn ich die Erfolge nicht zeigen kann, dann ist es irgendwie mein Fehler. Aber ich glaube in Wirklichkeit

ist die Anzahl der Erfolge gar nicht so hoch, prozentual gesehen, obwohl es natürlich in absoluten Zahlen schon einige gibt.

Was die Softwareentwicklung angeht, das hat meiner Meinung nach ein ganz ganz anderes Eigenleben angenommen.

Ja, spannend. Wir haben vorher immer das Coding als ein Bottleneck angesehen. Also das heißt, wir haben uns über Anforderungen quasi Gedanken gemacht. Wir haben das Backlog voll geschrieben und bisher war das Coden immer das Bottleneck. Also wir haben immer drauf gewartet, bis die Entwickler dann wirklich fertig waren und wir dann zum nächsten Feature gehen konnten. Mit Hilfe von AI haben wir jetzt quasi dieses Bottleneck einfach verschoben. Siehst, nimmst du das auch war?

war und wo sind denn deine Schwerpunkte? Also wie verändert sich das in dem Gesamteam jetzt dadurch, dass wir sagen wir kriegen jetzt Code einfach per Fließband sozusagen. Also wir diskutieren noch nicht über die Qualität, aber wir kriegen zumindest Features wesentlich schneller vermeintlich, weil wir nicht mehr lange darauf warten müssen, weil die AI uns da drastisch unterstützt.

Ja, das ist ein... Also ich würde... Ich kann das nicht allgemeingültig beantworten. Also ich würde mal sagen, ich habe an vielen Stellen das so nicht wahrgenommen. Also wir haben viele Unternehmen gesehen, auch in meinem Netzwerk mit Leuten in anderen Firmen, mit denen ich gesprochen habe, in denen das nicht der Bottleneck war. Also noch mal einen Schritt zurückzugehen, diese gesamte Ich schreibe eine Spezifikation in den Backlog und dann warte ich darauf, dass es programmiert wird.

Das an sich ist schon das, ich sagen würde, vielleicht nicht unbedingt die Art und Weise, wie man Software entwickeln sollte und vielleicht auch nicht das, was unbedingt klappt. Also die Idee, die ich wirklich vielfach im Funktionieren sehen habe, war ja gar nicht, die ganzen Requirements aufzuschreiben. Also ich erinnere mich noch gut daran, dass wir gesagt haben, a story is a promise for conversation. Also es ging nicht darum, in einer User Story, in einem großen komplexen Enterprise System.

die Anforderungen dann doch wieder so aufzuschreiben, wie man das vor 20 Jahren, Ende der 90er, versucht hat in den großen Requirements Dokumenten. Sondern es ging ja die enge Zusammenarbeitung, äh, Zusammenarbeitung, die enge Zusammenarbeit zwischen den Leuten, Software Engineers und dieses, wir brauchen ungefähr das. Man hat diese Deskchecks, man kann mit Leuten reden, man zeigt das und dann sagen die Leute ja so ungefähr und vielleicht besser, kleine Schritte zu gehen. Also dass diese Idee, dass da Software, dass das Programmieren der Bottleneck war.

Das würde ich nicht hundertprozentig unterschreiben. Und ich würde auch sagen, es gibt meiner Meinung nach genug Gegenmai- spiele, die eben zeigen, dass diese Trennung auch nicht funktioniert hat. Wir haben das gleiche, ich hab's auch mal irgendwann gepostet. Wir haben das gleiche ja schon mal versucht, vor 10, 15 Jahren in dem Outsourcing-Boom. Als gesagt worden ist, ich hab Unternehmen getroffen, die hatten wirklich nur noch Leute im Project-Management-Office, Leute, Spezifikationen geschrieben haben und eine Testabteilung. Und alles andere wurde outgesourct, es wurde gesagt...

Hier sind die Spezifikationen. Das waren Firmen, oft in anderen Ländern, Ländern mit niedrigerem Lohnniveau waren, wo dann gesagt worden ist, hier ist die Spezifikation, ihr implementiert das. Wir haben gar keinen eigenen Softwareentwickler, Softwareentwicklung mehr. Und wir kontrollieren nur das, was zurückkommt. Und ich würde mal sagen, in den allermeisten Fällen hat es nicht wirklich gut funktioniert. Was für mich ein Indiz dafür ist, dass diese Idee, dass man es im Vorfeld spezifizieren kann, eigentlich schon problematisch ist. Und deswegen würde ich eben sagen, diese Idee

Wir schreiben jetzt nur noch auf und die KI programmiert, dass das von Anfang an aus einem ganz prinzipiellen, tiefen Grund zum Scheitern verurteilt ist. Dass halt die Art und Weise, wie mit Genitive AI programmiert wird, eigentlich eher eine Verbesserung der IDEs ist. Aber die Interaktion zwischen den Leuten, die die Software brauchen, die Nutzende sind oder die den Überblick haben, die Product Owner, und den Leuten, entwickeln, dass die sich nicht wirklich verändert. Also dass nicht ein Product Owner sagt,

Die Spezifikation, die User Story, die ich so gepflegt habe, die inzwischen 15 Bildschirmseiten lang ist und jedes Detail beschreibt, die nimmt sich nicht von jemand, der Software entwickelt, sondern die wird jetzt von der KI programmiert. Das würde ich wirklich komplett ablehnen. Ich glaube nicht, dass das funktioniert.

Das ist nochmal eine interessante Sicht, immer wieder das Business mit reinzubringen und auch die Diskussion darum. Also das heißt wirklich zu verstehen, was implementiere ich hier und vielleicht auch dort die AI dann irgendwann mit einzubinden in eine Diskussion. Das ist richtig interessante Blickwinkel nochmal auf diese ganze Geschichte. Du hast gerade eben erwähnt, in dem Thema ist viel FOMO. Also wir kriegen alle gesagt, wir werden wesentlich effizienter dadurch und damit ist auch das Thema effizienter.

Effizienzmessung wieder ganz oben gelandet. Also wir hatten das im Developer Experience Bereich auch schon öfters, dass man einfach die Frage stellt hat, wie bekommen wir Entwickler effizienter? Und das Thema ist jetzt wieder neu hochgekommen, weil wir einfach sagen, diese Zahl, wir verbessern uns um 20, 30 Prozent, ist so gegenwärtig, dass wir jetzt oft messen wollen. Aus deiner Erfahrung, wie misst man dann Developer Experience oder

Developer Effizienz wirklich und sollte man es überhaupt messen?

Ich glaube, hängt bisschen damit zusammen, wo wir gerade sind in der Gesamtwirtschaft. ich denke mal, geht es halt schon viel darum, um Geld zu sparen. Die Wirtschaftslage ist so, dass die Firmen versuchen, mit weniger mehr zu erreichen. Ich denke mal, wenn man das Rad vielleicht zehn Jahre zurückdreht, als es noch keine Zinsen gab, als viel mehr Geld noch da war, auch um verschiedene Geschäftsideen auszuwählen, wäre es vielleicht darum gegangen, Sachen schneller zu programmieren und nicht vielleicht auch eine andere Art von Effizienz. Was ich auf jeden Fall aber sagen würde, ist, dass die, dass es

Ich würde mal so weit gehen zu sagen, dass es unmöglich ist, die Produktivität eines einzelnen Entwicklernden wirklich objektiv zu messen. Also wir haben das auch immer wieder diskutiert. Unser Chief Scientist Martin Fowler weist dann immer gerne auf den Artikel, den er 2004 geschrieben hat, wo drin steht, can't measure productivity. Und es ist ja wirklich so, es ist ja nicht, dass sich da noch keiner Gedanken darüber gemacht hat. Es ist ja nicht so, dass die Leute jetzt anfangen zu sagen, ach ja, jetzt wo wir die KI haben, da müsste man eigentlich ja mal gucken, ob man das messen kann. Das ist ja schon eine Geschichte,

seit den, keine Ahnung, seit den 70er Jahren, seit den 80er Jahren spätestens im Raum steht, sagen, wie können wir das messen? Natürlich schmunzeln wir heute alle darüber, gesagt wird, dass früher die Anzahl der Zahlen im Code, die eine einzelne Person, Software entwickelt, geschrieben hat, dass die als Polititätsmetrik genutzt wurden. Heute schmunzelt man darüber, aber ich glaube, über vieles, was wir heute machen, wird man in zehn Jahren auch schmunzeln, weil man einfach merkt, dass es nicht wirklich funktioniert hat. Wo ich sagen würde, was wirklich funktioniert, aber das ist

eben genau keine, nicht der Versuch einzelne Leute zu messen, sind die Four Key Metrics, inzwischen ja auch als Dora-Metrics bekannt und so weiter. Das sind schon Sachen, man zumindest, wo das Team dahinter, also Nicole Forsgren, Jez Humble und die Gene King, ich hab jetzt einen vergessen, glaub ich, wo die eben schon eine Menge Aufwand betrieben haben und auch mit einem sehr wissenschaftlichen Ansatz zeigen konnten, dass es Korrelationen gab zwischen diesen Metriken und Business Performance. Und da will man ja eigentlich hin.

Im Endeffekt kann es eigentlich, würde ich mal, wenn man wirklich mal von der Chefetage aussieht, kann es ja egal sein, wie schnell ein einzelner Entwickler ist. Die können ja auch einfach schlechten Code schreiben und ganz viel schreiben und Features, nicht benötigt werden und so weiter. Es geht ja eigentlich die Business Performance. Und was die 4K Metrics, die das Team dahinter bezeichnet, ja, dass diese 4K Metrics koalieren mit Business Performance. Und das ist ja eigentlich das, was ich wirklich sehen will.

Und natürlich sagt man dann, ja, das ist so spät und ich merke das dazu. Also kann ich im Nachhinein erst messen und so weiter. Ich möchte schon einen Leading Indicator haben und ich möchte jetzt aber doch die einzelnen Entwicklungen messen. nur weil man es gerne möchte, heißt es nicht, dass es auch geht.

oder dass es sinnvoll ist.

Oder ist es einfach?

Ich glaube, du hast auf das Buch Accelerate irgendwie gerade referenziert. Genau, wenn wir in die Show Notes noch mit reinbringen. Ja, das heißt, deine These ist hier, auf den Impact zu schauen. das heißt, was für ein Outcome bekommen wir auf der Business-Seite, wenn wir das jetzt machen? Also bedeutet das nur, weil wir viele Entwickler haben, die schnell ganz viele Releases deployen, heißt es nicht, dass wir dadurch einen Vorteil auf der Business-Seite haben. Also das heißt, das ist ja auch so ein Klassiker bei dem KPI, da gibt es ja auch so einen

Gesetz, glaube es ist das Good Hard Law oder sowas, das heißt, sobald eine KPI dann irgendwie eine KPI wird oder sobald eine Metrik eine KPI wird, werden alle Leute das tun, ⁓ diese KPI zu erfüllen, das heißt, wenn du Commit zählst, kriegst du Commits, wenn du Deployments zählst, kriegst du Deployments und am Ende zählt der Business Impact, also was kommt am Ende raus, wie können wir unser Business verbessern.

Ja klar. ich meine, das, was du beschrieben hast, da gibt es so viele Beispiele. Für euch selbst habe ich erlebt. Bei einer großen Investmentbank, einer Test-Suite. Ich glaube, es waren 200 Tests. Kein einziges Research Statement. Aber gute Test-Coverage. Weil Test-Coverage gemessen wurde. Das gleiche Beispiel gibt es auch tatsächlich so halböffentlich. Es gab mal so einen Blog, in dem Mitarbeitende von Microsoft so bisschen interner Preis gegeben haben. Und so ein Effekt ist halt auch bei Microsoft-Dokumenten hier voll. Ganz klar.

dass das, was gemessen wird, rauskommt. Aber die Frage ist ja im Prinzip auch...

Also, welchem Zeitrahmen nehme ich für solche Messungen auch? Wenn ich jetzt manchmal sage, ich habe dieses Feature heute in, sagen wir mal, großzügig 20 Prozent schneller implementiert, das macht keine Aussage darüber, was das für ein Software-System bedeutet, was fünf, zehn oder noch mehr Jahre weiterentwickelt werden muss. Das wird meiner Meinung nach wieder bisschen vergessen, aber wir haben da sehr viel darüber gesprochen als Industrie.

dass wir vom Projektdenken weggehen wollten und zu einem Produktdenken hingegangen sind. Das war ein Teil oder es hing so ein bisschen an ganzen Idee mit Microservices auch dran, dass man eben sagt, wir haben nicht einen Pool von Leuten, die Softwareentwicklung machen und dann werden die immer wieder neu zusammengewürfen, dann machen die ein Projekt da und ein Projekt da und ein Projekt da, sondern man sagt halt, wir geben denen Verantwortung für die Domäne und innerhalb der Domäne sind die Teams relativ stabil und arbeiten an irgendwas. Und wenn ich mir, wir haben hier in Deutschland sehr viel, ich persönlich auch mit Otto zusammengearbeitet.

Das ist eine große E-Commerce-Webseite und die haben eben auch viele stabilen Teams. Da ging es jetzt gar nicht mehr darum, Projekt möglichst schnell zu liefern, sondern wirklich nachhaltig. Die haben mit der Software angefangen so 2011 oder so. Das läuft schon 15, 16 Jahre, diese Software. Ich kenne auch Beispiele aus der Legacy-Modellisierung, wo das noch länger der Fall ist. Da ist eben dann die Frage, was erreiche ich damit, wenn ich jetzt irgendwie zeigen kann, ich habe die letzten 20 User-Stories 20 % schneller gemacht.

Ich weiß gar nicht, was es in Zukunft ist. Ich habe selber, dadurch, dass ich als Berater so lange tätig war, ganz, ganz viele sogenannte Rescue-Projekte gesehen, wo wir von Kunden reingeholt worden sind, gesagt haben, wir haben hier ein System und wir kommen damit einfach nicht mehr klar. Wir sind bezahlt worden dafür, mehr Zeilen zu löschen, als wir neu geschrieben haben. Einfach weil es so viel Duplizierung in der Code-Basis war. Ich habe eine Code-Basis gesehen, waren mehr Dupliz... Kein Scherz, mehr duplizierte Zeilen als überhaupt Zeilen.

oder lange Kotblöcke waren, die dupliziert waren und innerhalb der Kotblöcke nochmal wieder Dubletten drin waren. Und wie gesagt, also wirklich schnell ein einzelnes Feature einer einzelnen Person zu messen, hat einfach, ich weiß gar nicht, ist das eine Vanity-Metric, hat das irgendeine Aussagekraft, abgesehen von dem Effekt, den du beschrieben hast?

wo ich im Endeffekt darauf hin will, aber das ist eben dieses Geduldspiel, ist zu sagen, wenn mein Geschäft stark davon abhängt, dass ich ein Software-System habe, was mein Geschäft unterstützt, muss ich eigentlich im Endeffekt im Wesentlichen hauptsächlich darauf achten, wie sich mein Geschäft entwickelt. Da gibt es auch spannende Studien zu, müssen wir mal gucken, ob wir da noch zu kommen.

Ja, was für mich natürlich jetzt interessant ist, du bist auch ein Befürworter der Agilität in dem Bereich und oft mit Agilität hängt ja auch so was wie Scrum und Sprints zusammen. Fördert das nicht eigentlich auch genau dieses Verhalten? Also dass ich innerhalb von der kurzen Zeit quasi Tickets abarbeite und immer wieder in dieses Wir müssen liefern, wir müssen liefern, wir müssen liefern.

⁓ dann halt nicht genügend Zeit auch zu haben, mal drüber nachzudenken und quasi aus dem dauernden, aneinander gereiten Sprints dann wirklich mal eine Marathon Ansatz zu fahren. Und ist das eine nicht quasi ein Auslöser für das, was du eben beschrieben hast?

Das ist auf jeden Fall ein Effekt, den ich auch beobachtet habe. Das ist aber nicht, meiner Meinung nach, unbedingt im System verankert. Also die grundlegende Idee, und ich bin sogar ein Befürworter von kurzen Sprints, also ich bin ein Befürworter davon, einmal pro Woche zu machen, damit eben nicht solche Effekte kommen. Weil bei zwei-wöchigen Sprints und spätestens bei drei-wöchigen kommt schon sowas wie, lass uns mal einen Tag Codefrees machen vor dem Showcase und all diese ganzen Effekte, wo es dann doch wieder langsamer wird. Die Idee, das in Sprints einzuteilen, war ja eigentlich nur,

zu sagen, wir wollen, auf die Produktivität zu kommen, Gefühl dafür kriegen, wie schnell wir liefern können. Und wenn ich das wirklich, wenn ich jede Woche so einen Sprint oder eine Iteration abschließe, habe ich auch ganz, ganz viele Daten und kann einfach sehen, kann mich besser kalibrieren. Wir haben das bei Teams, länger zusammengearbeitet haben, die gut funktioniert haben, hinterher so gemacht, dass wir nur noch die User Stories gezählt haben. Wir haben die gar nicht mehr geschätzt. Wir haben einfach gesagt, in einer Woche kriegen, also wie gesagt, wenn so ein Team eingespielt ist,

Da denkt man ja auch an, die Stories einigermaßen in einer ähnlichen Größe zu machen. Aber selbst wenn die eine mal ein bisschen größer und die andere kleiner ist, statistisch hat sich das dann, oder gleicht sich das an vielen Stellen einfach aus. Jetzt werden wir zählenach bei den Stories und mit dem Team in dem aktuellen Kontext schaffen wir im Schnitt acht Stories pro Woche. Aber da wurde auch keinem der Kopf abgerissen, wenn das Team in der Woche mal sechs geliefert hat und alle haben sich gefreut, wenn es mal mehr waren. Aber es war wirklich eigentlich nur die Idee, rauszukriegen, wie

Wie viel Funktionität können wir liefern und was ist die Timeline von der Was natürlich passiert ist, und das ist durch einige Prozesse und vielleicht dann auch durch die Spezialisierung in dem Fall von einigen Rollen passiert, dass dann so was kam, wie ihr müsst ein Commitment abgeben und ihr Team, ihr Development Team seid schuld, wenn ihr euer Commitment nicht erreicht, weil ihr habt euch committed. Und ich kann mich an eine Situation erinnern, in der eine neue Person

verantwortlich war für einen Teilbereich von Softwareentwicklung und gesagt hat, ich habe jetzt eine Richtlinie rausgegeben, dass wenn ein Team seinen Commitment nicht schafft, dann müssen die mir erklären, warum sie es nicht geschafft haben. Und ich hatte den Effekt oft genug gesehen, also es war jetzt nicht so eine Eingebung in dem Moment, aber ich konnte in dem Moment deswegen relativ schnell antworten und sagen, das Einzige, was damit erreicht werden wird, ist, dass die Teams weniger committen. Weil diese Idee, dass es unangenehm ist, vom Chef zu gehen, wenn man seinen Commitment nicht erreicht hat, führt nur dazu, dass die Leute Sandbaggen.

Ja.

und ihr Commitment reduzieren, damit der Fall nicht eintritt. Das heißt, was man geschafft hat, ist, man hat nicht den Boden eingezogen, wo gesagt wird, die Teams werden durch die Sorge, ich will jetzt nicht Angst sagen, die Sorge, mit dem Chef vom Chef sprechen zu müssen, wenn sie ihr Commitment nicht erreichen, dazu beflügelt, aus irgendeinem Grund härter zu arbeiten, weil sie sonst ja faul sind. Sondern der Effekt ist genau andersrum. Deswegen, ich kenne die ganzen Effekte, das ist aber meiner Meinung nach nicht ein grundlegendes Problem mit Iterationen oder mit der Art und Weise...

die Gesamtfunktionen in kleinere Storys zu schneiden, sondern es ist vielleicht zum einen Teil der Unternehmenskultur und eben auch der Herangehensweise, der Verhältnis zwischen den Leuten, die Software schreiben und den Leuten, für den Geschäftserfolg verantwortlich sind.

Das heißt, wenn Projektcontrolling auf ein Produkt kommt, dann knirscht das hier und da. Aber trotzdem gibt es natürlich auch Deadlines und Lieferpunkte, wo man dann wirklich auch ein Release haben sollte. wenn man ein Team hat, was intrinsisch motiviert ist, das auch mit zu erreichen, mit zu gestalten, dann hat man mit Sicherheit mit diesen Abschätzungen, die du angesprochen hast, einfach auch ein Gefühl, wie viel ist man in der Lage, in diesem Zeitraum auch zu schaffen.

Ja und wenn die Stories klein genug sind, wenn die Kommunikation mit den Leuten, die die Software benutzen oder den Product Ownern, wenn es im B2C Bereich ist, wenn man mit den Leuten nicht so direkt spricht, wenn die klar ist, dann kann man in der Regel es schaffen, die Deadlines zu halten, weil man daran drehen kann, welche Features genau gebaut werden. Die Idee einfach zu sagen, es müssen...

unbedingt alle Features zu dem Zeitpunkt fertig werden. Das ist auch manchmal so bisschen mit dem Kopf durch die Wand. Also ich habe auch Bekannte, die in der Spieleindustrie arbeiten und da, also Videospieleindustrie und da gibt es ja eben heutzutage auch gar nicht mehr so sehr, aber immer noch diese ganze Idee, das muss halt komplett fertig sein, ansonsten ist es nicht spielbar und das muss an dem Tag, weil wir das angekündigt haben, fertig werden, dann werden dann 60, 80 Stunden die Woche gearbeitet. Crunchtime beginnt sechs Monate. Das habe ich im Enterprise Bereich in der Form nicht gesehen und es ist in der Regel auch nicht vom Erfolg gekrönt einfach. Also dieses

Wir, und da ist mir die Frage, muss ich mal fragen, in einem Satz mit Wir, das Wir ist, wir haben eine Deadline, die erreicht werden muss, da ist ein Passivsatz dann auch drin, dann wird gar nicht gesagt, wer die erreichen muss, und im Endeffekt wird es dann so gedreht, dass es halt nur daran liegt, dass die Entwicklenden nicht schnell genug sind. Weil die Deadline, war ganz klar, die war natürlich richtig berechnet und es sind natürlich die Leute, die die Software entwickeln, die alle eigentlich noch schneller arbeiten können, das aber aus irgendeinem unerfindlichen Grund nicht tun.

Ja, sagt wieder, alle sitzen in einem Boot. Es gibt nicht die Entwickler, die dran schuld sind. Und am Ende des Tages hilft nur zu sprechen. was oft auch passiert ist, hat man überhaupt am Anfang genug Informationen, so eine Deadline quasi punktgenau landen zu können? Also während des Entwicklungsprozesses oder während des Projektes oder wenn es keine Projekte sind, aber wie auch immer. Man lernt ja dazu. Also ganz viele Sachen, die weiß man am Anfang noch nicht, die kommen dann später mit rein. Und deshalb wollen wir ja auch kleinteilig unterwegs sein.

Ich würde gerne noch mal switchen. hast vorhin schon gesprochen, im Moment sind es wirtschaftlich angespannte Zeiten. da hat man ja oft diesen Gedanken wieder. Deshalb kommen wir auch von der Messung. Wir wollen die Effizienz messen und wir wollen aber auch mehr Kontrolle haben. Und da geht es dann oft darum, wie wollen wir jetzt vielleicht Komplexität reduzieren, dadurch dass wir sagen, wir definieren jetzt einen Golden Path da oder wir

Wir brauchen mehr Governance. Wie stehst du zu diesem Thema? Siehst du das auch? Oder ist das nur eine Beobachtung, die ich im Moment wahrnehme in der Industrie? Wie viel Governance braucht man?

Das ist eine gute Frage. Die Antwort hängt einfach so stark davon ab, was mit Governance bezeichnet wurde. Also das, ich eben beschrieben habe, zu sagen, wir machen kleine Iterationen, wir haben ein sehr gutes Verständnis dafür, sehr gutes Gefühl. Jetzt nicht so ein schwammiges Gefühl, sondern wir verstehen sehr gut, wie viel wir liefern können. Das ist auch eine Art von Die Idee zu sagen, wir wissen zu jedem Zeitpunkt, dass alle Tests grün sind, es ist die höchste Priorität, dass wenn ich

eine Regression in die Software einbauen und das hoffentlich in einem der Schritte der CD-Pipeline gefunden wird, dass das repariert wird, das ist ja auch alles Teil von Governance. Und ich finde, dass viele Teams, solche Praktiken leben, besser fahren und wie gesagt, wenn man sich die 4Key-Metrics, du hast das Accelerate-Buch erwähnt, wo die ja ursprünglich vorgestellt worden sind, wenn man sich die anguckt, dann merkt man, dass diese Art von Governance hilft. Oftmals als missverstanden, als

irgendwie Kontrollmechanismus als Drangsalierung, oftmals besteht ein gestörtes Vertrauensverhältnis zwischen Entwicklungsteams und der Geschäftsseite, aus welchen Gründen auch immer. Und ich verstehe natürlich auch, dass manchmal, wir hatten eben über Deadlines gesprochen, manchmal gibt es halt neue Gesetzgebungen, was ich im Healthcare-Bereichs, was wie die Elektronische Patientenakte oder die DSGVO, sie kamen. Und zwar es gibt bestimmte Sachen, die zu einem bestimmten Zeitpunkt fertig sein müssen. Aber auch hier

Manchmal hilft es ja nichts, die Peitsche zu schwingen oder schneller zu trommeln. Es führt einfach zu relativ wenig. Aber natürlich zu verstehen, wo man steht und was funktioniert, das ist mit Sicherheit immer hilfreich.

Und auf der Technologie Seite bist du eher ein Befürworter, so einen Technologie Stack vorzugeben und einzuschränken heißt das bei dir das, was das beste Tool für den Job aktuell auch mit der Gefahr, dass vielleicht andere Kollegen in der Organisation diese Technologie nicht beherrschen und dann nicht unterstützen können oder die, dann so ein Produkt erben, sagen, keine Ahnung, wie Rust funktioniert, wir müssen das Ganze neu schreiben. Wie siehst du es auf der Technologie

Seite.

Also da bin ich trotz allem, was ich vorher gesagt habe und was ich sonst so sage, schon eher konservativ. Also ich würde sagen bei einem Unternehmen, bei einer Organisation, die viele Leute hat, die Software entwickeln, macht es nicht Sinn, den einzelnen Teams zu sagen, nehmt was ihr wollt. das, ich meine an vielen Stellen funktioniert es technisch auch nicht wirklich gut. Also wenn ich Anwendungen habe, die im Browser laufen, die mit Komponenten, die aus Komponenten besteht, die von verschiedenen Teams geliefert worden sind, ist es in der Regel jetzt nicht so geschickte React und Angular.

Das geht technisch, wir haben es auch schon mal gemacht, irgendwie zusammenzubringen. Und das Gleiche gilt auch für die Serverseite. Ich glaube nicht, dass es irgendwie wirklich zielführend ist, Unternehmen fünf verschiedene Programmiersprachen benutzt werden, Microservices zu schreiben. Was spannend ist, ist die Frage nach der Evolution. Und da können tatsächlich Microservices helfen. Also zu sagen, wir machen heute Java und wir machen ein bisschen alle Ewigkeit Java ist auch nicht die richtige Strategie. Das heißt, wenn ich kleinere Service habe und bei Microservices ging es

Kann ich jetzt sagen, jemand, wirklich da mitten im Epizentrum war, von der ganzen Revolution, ging es ja nie darum, die möglichst klein zu machen. Es ging ja nur darum, das hieß ja immer so groß wie es, dass es noch in James Kopf reinpasst oder so. Auf jeden Fall, dass man aber abgeschlossene Grotteile hat und da mit neuen Sprachen mal gezielt und bewusst experimentiert. Das macht Sinn. Also wenn ich zum Beispiel sage, wir haben

Viele, viele, wir haben vielleicht einen existierenden Legacy-Monolithen. Wir haben angefangen, da Microservices rauszuschneiden. haben das gemacht, der Monolith war damals in Java geschrieben. Wir haben jetzt angefangen, die Microservices auch in Java zu schreiben. Aber wir bekommen mit, dass vielleicht eine Programmiersprache wie Kotlin die Entwickler etwas produktiver macht. Wieder da die Frage, wie kann man es messen? manchmal ist es auch einfach so, dass man an der Stelle sehen kann, wie die Leute damit umgehen. Und dann kann man anfangen zu experimentieren und kann sagen, okay, wir machen jetzt wirklich mal ein Instrument und wir machen halt...

zwei, drei Services von diesem Microservices in Kotlin gucken, wie das läuft und kann dann graduell vielleicht, man würde ja nicht die existierenden Services neu schreiben, aber man würde dann vielleicht nach einer Zeit sagen, okay, das hat sich jetzt bewährt. Wir haben auch angefangen, tiefere Expertise im Unternehmen zu haben. Wir haben vielleicht ein paar Leute eingestellt, die Experten sind. Wir haben eine Art und Weise zu arbeiten, dass wir nicht in Siloes arbeiten, sondern Collective Code Ownership haben und die Leute dadurch diese Neutechnologie dann so langsam in so Wellen eingeführt haben, sodass dann in vielleicht fünf Jahren, sechs Jahren vielleicht dann der Großteil

der Service System Kotlin geschrieben ist, in einiger älteren Java, dass man halt so eine gesteuerte, graduelle Weiterentwicklung hat. Das gleiche gilt auch für Frameworks.

Wie findet man da die richtige Balance? Weil am Ende des Tages wollen, hattest du ja gesagt, bist du eher konservativ von der Einstellung hin, also eine Technologie oder einen Satz an Technologien. Und auf der gleichen Seite wollen wir Innovation. Also Innovation bedeutet, mit neuen Sprachen experimentieren, vielleicht andere Cloud-Services mit reinbringen. Und wenn ich jetzt sage, wir wollen das und wir eine größere Organisation haben, dann kommen plötzlich Hunderter auf mich zu und sagen, okay, wir wollen jetzt innovativ sein oder das ist genau das Ding, was wir jetzt

wollen. Da ist ja die Frage, wie kriegt man diesen Trade-off hin? Es gab irgendwann mal einen interessanten Blogpost, wo es Innovationstoken geht, wo die Teams sich sozusagen eine Anzahl an Innovationstoken gegeben haben, wo sie unabhängig einfach mal ausprobieren und aber auch sehr schnell gemerkt haben, wenn sie die Token zu viel ausgeben und zu viel Innovation reinbringen, ist das Produkt nicht mehr managebar. Wie schätzt du das mit dieser Balance ein? Wie bringt man das in die Praxis, was du eben gesagt hast?

Es gibt da keine allgemeingültige Antwort. Ich kenne das von ganz verschiedenen Ansätzen bei den Unternehmen. So etwas wie du mit den Tokens habe ich auch schon gesehen. ist teilweise aber auch so, dass du bei einer bestimmten Größe einfach so viele Leute hast, Software entwickeln, dass einfach vielleicht ein Bereich, die, wenn wir jetzt über Innovation sprechen, sprechen wir ja nur über Innovation, bei der Softwareentwicklung. Das sind ja nur die Werkzeuge.

In Willigkeit geht es den meisten Unternehmen ja nicht die Innovation in den Werkzeugen, sondern darüber, als Unternehmen innovativ zu sein, also bessere Lösungen zu bauen. Und das vielleicht an bestimmten Stellen, wo eine modernere Technologie oder bestimmte Fähigkeiten dieser Technologie da zu helfen, wo es klarer ist, durch eine Analyse zu sehen, hier kann ich mehr Geschäftswerte erreichen, hier kann ich als Unternehmen innovativer sein, dass in diesen Teams halt solche neuen Technologien ausprobiert werden und in Teams...

Banking-Bereich, ganz grob zum Beispiel Frontoffice und Backoffice oder man kann halt zwischen, weiß ich nicht, auf einer Webseite vielleicht zwischen einer Suchfunktion und einem Orderfullfillment unterscheiden. Also, dass man vielleicht in den Bereichen, wo man argumentieren kann, plausibel argumentieren kann, aufgrund von Erfahrung, Erfahrung wird auch wirklich massiv unterschätzt an vielen Stellen, argumentieren kann, dass eine moderne Technologie und dass eine innovative Technologie hier, dass man eine Linie ziehen kann zwischen einer innovativen Technologie und

mehr Business wert, dass da dann die Experimente gemacht werden sollen. Wohingegen in anderen Bereichen gesagt wird, also wir haben jetzt hier jahrelang dieses eine Framework benutzt oder kann auch. Und hier ist ein neues Framework. Wir schreiben jetzt alles neu in dem neuen Framework und alles wird gleich gut, aber wir sind fünf Prozent schneller. Da würde ich immer sagen, dann sind wir doch am Governance Thema. Aber da ist dann wirklich einfach auch viel Erfahrung, aber Erfahrung, die eben sich darauf konzentriert zu gucken, was erreicht das in Summe für das Unternehmen oder für den Teilbereich, für die Lösung, die von dem Software-System abgedeckt wird.

Ja, also auch da rauszuhören der Business Impact. wenn ich dieses Investment jetzt mache, ist das jetzt ein Investment, was mir eigentlich das Gleiche wieder nur in einer anderen Geschmacksrichtung bringt oder habe ich hier einen Business Impact, der uns auf irgendeine Art und Weise verbessert?

Du hast aber auch

intern bei größeren Firmen ganz andere Probleme, die Wahrheit zu sagen. Was ich viel gesehen habe bei dem, ich würde jetzt mal schon fast sagen, dem Übergang von eigener Infrastruktur zu Cloud, war, dass in Unternehmen natürlich die Leute, im Betriebsbereich waren, und selbst wenn man DevOps macht, DevOps hieß für mich jetzt nicht, dass alle alles machen. Ich hatte ja gesagt, dass bei einem bestimmten größeren Platform-Team sinnvoll ist. Aber dass du natürlich da ganz heftige Diskussionen hattest, dass die Leute

die intern verantwortlich waren für die Serverfarm, für den Betrieb des eigenen geließten Rechenzentrums, dass sie natürlich hunderte von Gründen gefunden haben, warum es keinen Sinn macht, AWS oder hinterher Azure und zu GCP zu gehen. Aber das ist einfach existenzbedrohend gewesen in dem Fall. Die Leute haben einfach gedacht, so Moment, wenn die, das Unternehmen, bei dem ich arbeite, wenn die jetzt in die Cloud gehen,

dann habe ich gar keinen Job mehr, weil mein Job meine Spezialisierung war, VMware und Puppet und Chef die Server zu verwalten. Also, was soll ich meine? Irgendwann kollidieren dann auch persönliche Interessen und der eigene Beruf, die eigene Rolle mit der Einführung von neuen Technologien. Und dann kann es natürlich schwer werden.

Ja, 100 prozentig. Aber das ist auch ein gutes Stichwort. Wir sehen ja sehr viel Bewegung in dem ganzen Bereich. Wir haben auch einen demografischen Wandel sozusagen. Wir verlieren früher oder später irgendwann Leute, die eine Software entwickelt haben. Aber die Software existiert noch weiter und sie existiert vielleicht in der Technologie, die wir aktuell nicht mehr so ganz gut durchdringen können, nicht mehr beherrschen. Also es gibt ganz viel im COBOL Bereich, im Finanzsektor. Aber heutzutage

Es ist auch so, dass C++ zum Beispiel nicht mehr präferiert eingesetzt wird, man vielleicht lieber Java hat oder andere Sprachen hat. Und einige Firmen haben dieses Problem der Applikationsmodernisierung. Da hast du auch schon sehr viel Erfahrung bekommen oder erreicht in dem Bereich. Was sind denn so diese Sachen bei so einer Legacy-Migration? Ist es der Greenfield-Ansatz? Ist es ein Mythos oder existiert er wirklich oder wie kriege ich am besten

Ich habe hier ein altes System, das bringt unseren Umsatz oder das hat seinen Business Wert für uns. im Prinzip gehen die Leute oder das Know-how geht, was die Prozesse kannte, was vielleicht auch die Entwicklungssprache kannte. Wie geht man damit am besten

Also das nochmal zu unterstreichen, ist ja nicht nur, dass die Leute gehen. Normalerweise würde man sagen, dann stellen wir neue Leute ein. Ich meine, viele Leute, im Softwareentwicklungsbereich arbeiten, sind in Deutschland an der Uni an der Fachhochschule gewesen, haben Informatik studiert. Die kommen jetzt auch nicht unbedingt mit dem Tech Stack aus der Uni. Das ist ja keine Berufsausbildung, was die Leute an der Uni machen. Das heißt, man könnte ja schon einfach sagen, warum nicht? Dann lernen die halt COBOL Wenn sie sowieso eine neue Programmiersprache lernen müssen, können sie auch COBOL lernen.

Aber was eben hier passiert ist auch, das habe ich bei einigen Firmen gesehen, die Technologie eingesetzt haben, die nicht mehr aktuell ist, dass sie Probleme haben, Leute überhaupt einzustellen. Also ein interessantes Beispiel, mal von dem Cobol-Beispiel wegzugehen, ist ein sehr bekanntes großes deutsches Unternehmen, die einen wesentlichen Bestandteil ihrer Software, den internen Teil, immer noch als Swing-Applikation. Swing ist eine User-Interface-Technologie im Java-Umfeld, die eben nicht browserbasiert ist.

Und die funktioniert. Die haben wirklich gut gearbeitet. haben eine funktionierende Software, die sich jetzt inzwischen über Jahrzehnte gehalten hat. die Software stellt gar kein Problem dar. Das Problem ist der Arbeitsmarkt. Wenn die versuchen Leute einzustellen, dann sagen die Leute, Moment, wenn ich jetzt bei euch anfange, dann lerne ich die Details von Swing in einem großen Legacy-System. Das macht mich im Prinzip für den Arbeitsmarkt unattraktiv, wenn ich jemals hier weggehen wollen würde, weil alle erwarten, dass ich, wenn ich drei Jahre gearbeitet habe, auch drei Jahre irgendwie JavaScript gemacht habe im Frontend-Bereich.

Das kann gleichzeitig auch noch Problem werden. Es ist nicht so, dass die Technologien immer automatisch den Zweck nicht mehr erfüllen oder dass es unmöglich ist, die zu lernen. Sondern dass es einfach der Wandel der gesamten Industrie da einen gewissen Druck ausübt. Ich glaube, bei dir schwang noch die Frage mit, wie macht man es dann? Wie macht man Legacy-Modernisierung? Und da heißt es natürlich, ich bin doch harter, die Antwort immer, depends. Also das hängt halt einfach viel zu sehr von der Größe ab.

Wie gesagt, hatte anpänig mal vom Guardian gesprochen. Ich glaube bei Otto, die haben das auch selbst gebloggt Das waren Systeme, die eben in ihrem Bereich, der Guardian-Content-Management-System und Otto eine E-Commerce-Plattform hatten und gesagt haben, wir brauchen jetzt Custom-Software. Das konnte natürlich dann nicht mehr so ganz scheibchenweise abgelöst werden, obwohl es auch da interessanterweise Muster gab. Wir sprechen da gar nicht mehr so viel von. Wir haben halt oft so gearbeitet, dass wir so eine Bubble erschaffen haben, so eine Art...

Ich will nicht Bauern der Kontext sagen. So eine Art Bubble geschaffen haben, in der die Customer-Facing-Sachen zunächst neu programmiert werden konnten und dann über so temporäre, wir haben das auch mal Transitional Architectures genannt, über so temporäre Architekturen vielleicht noch so ein bisschen zusammengehackt, die alten Systeme im Hintergrund waren. Dass erst mal gucken konnte, auf den Geschäftsfeld zurückzukommen, was bringt es denn eigentlich, wenn ich die Software neu schreibe für die Kunden und Kundinnen? Und dann nach und nach im Laufe der Zeit dann

die älteren Systeme, die weiter hinten, weiter weg von der eigentlichen Kundeninteraktion waren, dann auch modernisierter. So ein Scheibchenweise ansatz. Und wie man die Scheibchen schneidet, ist natürlich unterschiedlich. Manchmal kann man vielleicht auch Produktklassen ändern. Ahnung, wenn ich in der Automobilindustrie bin, dann mache ich vielleicht, keine Ahnung, erst mal nur Teile der PKWs oder nur die E-Autos oder ich fange mal mit irgendwas wie kleinen Transportern an oder irgend sowas und gucke, ob ich da so Schnitte finden kann. Aber das ist...

Ich glaube, da gibt es genug Dokumentationen. gibt auch von Kollegen hier Rob Horn Ian Cartwright und so, haben auf Martins Webseite auch geschrieben, Legacy Displacement Patterns. Also die haben auch so einen ganzen Katalog mal beschrieben, wie man da vorgehen kann. Und um noch einmal die Steilvorlage zu geben, natürlich in der heutigen Zeit, hilft natürlich Retrieval, Augmented Generation und Gen.AI Teams zu verstehen, was überhaupt in den Millionen von existierenden Code passiert.

Also

Weil selbst die Leute, wie du gesagt hast, die jetzt älter werden, die vielleicht aus dem Berufsleben ausscheiden oder neue Jobs machen, die wissen auch nicht mehr genau, was da irgendwo war. Oder gerade im Finanzbereich, im Versicherungsbereich, nachdem dann die siebte Merger und Acquisition stattgefunden hat und irgendwelche Systeme zusammengestückelt wurden, das weiß im Detail auch die Leute, die es gemacht haben. Also es wissen auch die Leute, die es gemacht haben, im Detail wahrscheinlich nicht.

Das heißt, du hast auch einige Projekte dort mit begleitet, die das mit Hilfe von KI gemacht haben. Und wie sieht sowas denn im Detail aus? Also mache ich die Magic Box auf, schiebe den Code rein und sage einmal bitte in Java oder wie ist der Ansatz?

Ja,

das hätten wir alle gerne. Unser Erfahrung ist, dass es definitiv heute noch nicht funktioniert und das noch benutze ich auch vorsichtig. Ich bin mir nicht sicher, ob es jemals wirklich in der Form funktionieren wird und ob es auch in der Form funktionieren sollte tatsächlich. Also, ob man wirklich diese eins zu eins Feature-Kopie haben will in einer neuen Technologie, wo es wirklich geholfen hat und da gibt es auch jede Menge Material, das können wir nochmal verlinken dann. Die Kollegen haben das, das ist ein internes

Werkzeug, das heißt Code Concise. Da gibt es genug Artikel und so weiter, deswegen will ich nicht groß in Detail eingehen. Im Prinzip ist es aber eine Retrieval Augmented Generation Lösung, in die im Vorfeld der Code eingepflegt wurde, wenn man das so sagen will, wo der Code beschrieben wurde. Wir sind ein bisschen weiter gegangen, haben auch klassisches Reverse Engineering benutzt, strukturelle Informationen zu bekommen, die in der Grafdatenbank hinterlegt sind, dann im Prinzip ein System zu schaffen.

dass mir den existierenden Code besser erklären kann. Und das haben wir gesehen, das hat wirklich an... Also es gibt einen Fall, ich darf den Kunden glaube ich hier gar nicht nennen, da ging es eine Legacy-Modernisierung tatsächlich von Cobol und die hatten schon ein längeres Programm aufgesetzt, war ein wichtiges System und hatten eine gute Baseline. Das ist ja oft auch das Problem, wenn man Produktivität oder Änderungen messen will, dass die Baseline fehlt und dann sagt man...

Wir sind jetzt heute so schnell, aber wie schnell waren wir glaubwürdig in der Vergangenheit. Aber die hatten tatsächlich eine Baseline und hatten auch eine relativ gute, die haben das so schreibchenweise gemacht, wie ich schon beschrieben habe, und hatten ein gutes Verständnis davon, wie lange das dauert, eine solche Scheibe zu machen. Und wir konnten zeigen, dass der Hauptbottleneck an der Stelle tatsächlich nicht die Entwickler waren, sondern die Subject Matter Experts. Und dieses System, dieses

Retrieval of augmented generation system in Gen. hat geholfen, viele Fragen der Teams, die die neue Software schreiben sollten, zu beantworten, sodass die Subject Matter Experts nicht mehr gebraucht wurden. Und man konnte dann diese einzelnen Scheiben dreimal so schnell liefern. Es war eine Reduktion ⁓ 66,7 Prozent. Wie gesagt, das ist ein Fall. Ich will jetzt nicht sagen, das ist immer so schnell, aber an der Stelle haben wir schon gesehen, in diesem Reverse-Engineering-Bereich, dass man da Teams wirklich sehr, sehr gut unterstützen kann. Und ich bin ein bisschen überrascht auch tatsächlich, dass

so viel Augenmerk darauf gerichtet wird, wie ich noch mehr, noch schneller, noch mehr Code generieren kann mit KI. Wo dann die ganzen Effekte eintreten, die wir schon besprochen haben, was ist in einem Jahr, was ist mit Bugs und so weiter und so weiter. Und noch gar nicht so viel Augenmerk darauf gerichtet, wie kann ich denn diese neuen Technologien einsetzen, Reverse Engineering zu machen. Weil die Wahrheit ist, ich meine, ich habe viel im Enterprise-Umfeld gearbeitet oder arbeite viel im Enterprise-Umfeld. Da ist einfach unglaublich viel existierender Code.

Da wird gar nicht so viel Greenfield programmiert

Ja, ganz klar. Das heißt, das Entscheidende dort ist auch wieder ...

nicht einfach auf Masse zu gehen, sondern gezielt ein Verständnis zu erlangen, was ist in dem Code passiert und dort vielleicht auch diese Subject Matter Experts zu skalieren in Form von ich kann den Code selbst fragen. Ich weiß wirklich, was da passiert und was du am Anfang in so einem Nebensatz gesagt hast, ist natürlich auch super spannend. Wenn ich eine neue Technologie einsetze, möchte ich natürlich auch die Vorteile davon nutzen, beziehungsweise wenn ich ein System anfange, möchte ich auch besser rauskommen, also nicht eins zu eins, sondern nur reinzugehen, weil

Das ist ein sehr guter Zeitpunkt, Sachen vielleicht auch zu überdenken und nochmal neu zu machen. Richtig spannend.

Es wird eben auch viel über die großen Sachen gesprochen.

Und das kommt immer auf die Frage zurück mit der Innovation. Manchmal sind es aber auch einfach die kleinen Sachen, die dann doch wieder übersehen werden. Wir haben ein Team, also ich kenne ein Team, die gesagt haben, der Wechsel von Poetry zu UV, das ist ein Package Manager für Python, also Poetry ist schon der etwas modernere und UV, also UV, ist der ganz neue. Das hat so viel mehr Politität gebracht als die Einführung von AI-assisted Software Delivery Tools, weil die Bildzeiten einfach so dramatisch reduziert wurden.

Und dann wird das so bisschen abgetan, weil, ja, okay, ich hab da einen neuen Package Manager benutzt. man muss schon wirklich gucken, was funktioniert denn eigentlich wirklich. Und da ist natürlich dann so ein bisschen die Kunst zu gucken, wo kriege ich die Information her, woher wusste das Team überhaupt, dass es UV gab und hat nicht einfach Poetry benutzt. Und da muss man eben auch ein bisschen aufpassen, wenn man jetzt noch mal über die AI-assisted software, die wir choose, spricht, wenn man denen jetzt zum Beispiel sagt...

machen wir mal ein Proof of Concept, dann nimmt es natürlich das, dominierend im Internet war. Aber nicht die Nischenmannung. Und das ist eben wieder die Erfahrung, die nicht unterschätzt werden darf. Ich habe neulich, ich weiß gar nicht mehr, Beers gepostet auf LinkedIn, so netten Cartoon gesehen. Da ging es ⁓ diese Idee dreht sich die Erde die Sonne oder andersrum. Und die Antwort zu dem Zeitpunkt von einem GPT-System wäre natürlich gewesen, natürlich.

Mmh.

dreht sich die Sonne die Erde, weil das die vorherrschende Meinung in allen Texten war und das andere eine Ausnahmemeinung war. Also diese Idee, neue Sachen auszuwählen, das kann uns ganz gut verstellt werden durch die AI-Assisted Tools.

Wenn man sich zu 100 Prozent nur darauf konzentriert und darauf verlässt und manchmal ist unser Engineering Wissen oder nicht nur manchmal, sondern sehr oft, es das, was uns dann halt wirklich voranbringt und was wir nach wie vor auch brauchen. Du hast noch ein weiteres Steckenpferd, was du so als Ambassador sozusagen voran treibst. Das ist Green IT und wir haben jetzt ganz viel über KI und Cloud schon gesprochen. Wie passt denn aus deiner Sicht Cloud und KI mit Green IT zusammen? Funktioniert das überhaupt?

Das muss man trennen, würde ich mal sagen. Cloud und GreenRT passen relativ gut zusammen. Viele der Möglichkeiten, wie ich die Energie reduzieren kann, die ich brauche, eine Softwarelösung laufen zu lassen, funktionieren besser in der Cloud als in eigenen Rechenzentren. Also es fängt an bei diesem sogenannten Power Usage Efficiency Faktor. Das ist die Menge an Elektrizität oder Energie, die ich brauche, außerhalb der Server.

⁓ die Lösung laufen zu lassen. Also Klimaanlagen und so weiter, alles, was in den Rechenzentren ist. da muss man wirklich sagen, vielleicht gibt es kleine Ausnahmen, aber in der Regel sind da die großen Cloud-Anbieter allein aus wirtschaftlichem Interesse auch so viel weiter, also ein gutes Stück weiter als die anderen Rechenzentren, sodass alleine tatsächlich der Wechsel von einer Lösung von einem eigenen Rechenzentrum in den Cloud schon eine signifikante Reduktion bedeuten kann. Ich habe hier leider nur, da gibt es nicht viele Zahlen in dem Bereich, da wird nicht so gerne darüber gesprochen, aber es gibt ein öffentliches Beispiel von Etsy.

also Etsy, der Markt für handcrafted items. Die waren in einem eigenen Rechenzentrum und hatten einen Power Usage Efficiency Factor von 1,4. Das heißt, für jedes Kilowatt Strom, das sie verbraucht haben, sie noch mal 400 Watt verbraucht für den Rest. Die sind damals zu Google, zu GCP gewechselt und die hatten einen Power Usage Efficiency Factor von 1,1. Das heißt, die hatten eine Reduktion, wenn man es ausrechnet, von ungefähr 20 Prozent des Energiebedarfs allein dadurch, dass sie es nicht mehr im eigenen Rechenzentrum betrieben haben.

sondern den wesentlich effizienten Rechenzentren eines großen Cloud-Providers. Und andere Sachen, zum Beispiel sowas wie diese ganzen Möglichkeiten, die Rechenlast zu verteilen, also zu sagen, ich lasse vielleicht einen Batchjob nachts laufen, wo die Rechner zwar da sind, aber anderweitig nicht benutzt werden. ich kann sogar, und das wird versucht, da gibt es viele Komplikationen bei, zum Beispiel zu sagen,

Ja, das ist spannend.

Es gibt eine schöne Studie, die Microsoft und UBS in dem Bereich gemacht haben. Ich versuche mal, Batchjobs, irgendwann in der Nacht laufen zu lassen, dann laufen zu lassen, wenn der Strommix, und die Daten sind inzwischen verfügbar, wenn der Strommix ein bisschen grüner ist. Also wenn ich in der Nacht nach Wetterfeuerseite sehen kann, zu dem Zeitpunkt wird es mehr Wind geben, dass ich dann anfange, die Batchjobs dann laufen zu lassen. Allerdings ist das ein unglaublich kompliziertes Themenfeld, weil ich natürlich dann sage,

Wenn ich den grünen Strom benutze, jemand anders macht das Gleiche, dann müsste doch ein Gaskraftwerk hochgefahren werden. Das ist bisschen kompliziert zu sagen, aber viele von den Praktiken und Möglichkeiten, die da existieren, funktionieren eigentlich nur dann, wenn ich unglaublich viele Server habe. Und das ist eigentlich in der Cloud der Fall. wenn ich, keine Ahnung, ich das immer angenommen, werde, die machen es hier nicht mehr, aber ich werde ein sehr großes E-Commerce-Unternehmen, dann müsste ich ja jede Menge Server vorwärtig halten für die Cyber Week und für das Weihnachtsgeschäft usw. Und den Rest des Jahres stehen die rum.

Und Server, die Energieeffizienz von Servern, wird es besser, wenn die nah an der Auslastungsgrenze sind und nicht, wenn sie nah am Leerlauf sind, weil die im Leerlauf immer noch so 20 Prozent des Stroms verbrauchen, auch wenn sie nichts tun. Und in der Cloud, wo sich viele Leute mit unterschiedlichen Anbindungsprofilen die gleichen Server teilen, kann ich das besser gegeneinander ausspielen.

Interessant. Also ich glaube auch, ist das, was man ja sieht. Auf der Infrastruktur-Ebene wird optimiert. Wann fahre ich was hoch? Kann ich Sachen runterfahren, die ich aktuell nicht brauche? Kann ich dynamisch skalieren? Und das sind alles Toolings, die die Cloud Provider heutzutage out of the box mitliefern. Siehst du da einen Vorteil, dass das quasi auch mit ökonomischen Effekten zusammenhängt? Also das heißt, wenn ich die Rechner irgendwann abschalte, muss ich nicht so viel dafür bezahlen. Und bei Rechnen

Zeit ist quasi auch Bezahlzeit und ist aber auch gerade Verbrauchszeit von Energie. Also hilft das dem Thema, dass das nahe aneinander liegt oder siehst du das oft losgelöst betrachtet?

Also theoretisch auf jeden Fall praktisch ein bisschen zwiespältiger, aber immer noch positiv, würde ich sagen. Also ich glaube schon, dass die Art und Weise, bei den meisten Unternehmen Cloud-Technologie eingeführt worden ist, dass ein besseres Verständnis davon ist, wer welche Kosten verursacht. Also ein VP Engineering, mit dem ich eng zusammengearbeitet immer wieder von den e-DA-Servern gesprochen. Also die Server, die e-DA sind. Und da hat dann keiner so wirklich auf den Stromverbrauch von den Servern geachtet. Und die waren da. dann manchmal werden die Systeme auch

Zombie-Server genannt. Also das sind dann so Server, wo alle da so, ja, also eigentlich, ich glaube, wir brauchen den nicht mehr, aber ich bin mir nicht so sicher, lass den lieber mal laufen. Und das passiert, glaube ich, im eigenen Rechenzentrum viel häufiger. Es ist nicht so, dass es in der Cloud nicht auch passieren kann, aber es passiert im eigenen Rechenzentrum häufiger und in der Cloud seltener, weil eine bessere Kostentransparenz da ist, weil dann doch mal geguckt wird, ja, guck mal, wie viel Geld wir hier ausgegeben haben für diese Servers, was machen die denn jetzt eigentlich wirklich? Und wir haben Kunden auch immer wieder geraten.

Du kannst ja in der Public Cloud, im eigenen Rechenzentrum zum Teil, auch in der Public Cloud relativ gut so Tags vergeben an die Systeme und die dann nach Business Funktionalität, wie ich eben zum Beispiel sagte, eine Artikel-Detailseite oder ein Order Capture, dass dann wirklich die entsprechenden Systeme in der Cloud so getaggt sind, dass man dann zuordnen kann, wie viel kostet denn der Betrieb der Systeme, die diese Business Funktionalität erfüllen. Und ich habe auch bei Kunden Fälle erlebt, wo wir

allein schon bei so einer, wie sagt man das Deutsch, Back of the Envelope, bei so einer groben Überstachskalpulation gesehen haben, die Betriebskosten werden so hoch sein, dass der Business Wert gar nicht da ist. Also ich glaube, das ist da schon ein bisschen mehr und führt natürlich dann, wenn die Leute merken, sie haben eine Kostenkontrolle, dann geht es natürlich relativ schnell in die Kostenreduktion und im großen Zusammenhang ist da ja die Idee, dass wenn es weniger kostet, weniger Rechenzeit verbraucht wird,

und dann auch weniger Energie verbraucht wird und es deswegen dann noch zu weniger CO2-Ausstoß führt.

Wie weit hängen da mit Programmiersprachen zusammen? Also wir haben ganz viel über die Infrastruktur gesprochen.

Java hat oft noch den Mythos mit sich, dass es eher für die Rechenzentren unterwegs war und dass es eine große Image mit sich bringt, viel Speicher braucht. Im Moment kommen solche Sprachen wie Rust, Odin, Zig, die sehr C nah sind, sehr optimiert sind, die natürlich auch wesentlich kleineren Footprint haben. Lohnt es sich in dem Bereich, dort in so eine Sprache zu investieren und macht das wirklich einen Unterschied oder?

sind die geeigneten Maßnahmen, erst mal zu schauen, was brauche ich überhaupt wirklich und das auszuschalten.

Also die Antwort ist ja, es macht einen Unterschied. Die Frage ist, wie groß ist der Unterschied und wie sinnvoll ist es deswegen, so etwas zu machen. Es gibt eine immer wieder zitierte Studie, weil es eine der wenigen ist, es gemacht haben. hat ein Forschungsteam verschiedene Programmiersprachen analysiert und geguckt, wie energie- und speichereffizient die sind. Ich würde mal sagen, die ganze Speichereffizienz ist relativ uninteressant. Also die großen Treiber von Energieverbrauch sind Rechenleistung,

im Wesentlichen vielleicht so permanenter Speicherplatz, also auf SSDs und Festplatten, weniger der Hauptspeicher von dem System. Und Netzwerk Traffic ist noch mal eine ganz eigene Geschichte. Wie dem auch sei, die haben das geguckt, die haben geguckt, wie Energie, die haben Standard Benchmarks genommen, die in der Industrie verwendet werden, haben geguckt, wie energieeffizient, gemessen, wie energieeffizient sind die Sprachen tatsächlich, haben C als Baseline genommen und als 1 gesetzt und haben dann geguckt einfach als Faktoren.

Rust ist tatsächlich mit 1,05 oder so wirklich unglaublich nah dran gewesen, sogar noch deutlich näher als C++. Da kann man jetzt wieder sagen, wie idiomatisch war das, haben die halt vielleicht viele V-Tables benutzt, wo man halt Statics hätte benutzen können und so weiter. Also die Studie ist mit Sicherheit auch schon, oder ist mit Sicherheit auch verschiedenen Stellen kritisiert worden. Aber es ist auch als größten Vermerk was interessant war, Java kommt dann mit dem Faktor von zwei weg, was ich für unglaublich gut halte. die Java-virtuelle Maschine ist wirklich über die zwei, drei Dekaden.

Keine Ahnung, wann die genau angefangen haben, also irgendwann in 90ern. Fast 30 Jahre, unglaublich gut geworden. Sie sind bei einer Faktor 2 nur. Interessanterweise, dem Zeitpunkt, als die Studie gemacht wurde, war JavaScript bei einem Faktor von 4. Also wenn man provokant sein will, kann man sagen, benutzt bitte nicht Node auf dem Server, sondern im Java und dann habt ihr den halben CO2-Ausstoß. Aber das ist natürlich eine sehr plakative Aussage, da hängen ganz viele verschiedene andere Sachen dran. Und ich würde auch sagen, wir haben es versucht, an einigen Stellen, ich habe selber auch in Rust programmiert,

mir das genauer angeguckt, zu sagen jetzt, du sagst, Java ist doppelt so effizient nach der Studie wie JavaScript, aber Rust ist noch mal doppelt so effizient, lass uns doch mal die Microservices in Rust schreiben. Und da muss man dann wirklich sagen, irgendwann macht es auch keinen Sinn mehr, der Stelle das nur noch für die Effizienz zu tun. Also der Aufwand, einen Service in Rust zu programmieren, ist doch deutlich höher, abgesehen von der Verfügbarkeit der Leute am Arbeitsmarkt und so weiter, so weiter, verschiedener anderen Rahmenbedingungen.

dass man da dann irgendwann sagen muss, macht es jetzt wirklich noch einen Unterschied oder kann ich andere Maßnahmen treffen. Vielleicht ist es auch irgendwie ein Index auf einer Datenbank-Tabelle oder eine andere Sache, ich durch gutes Performance-Testing, da haben wir ja am Anfang darüber gesprochen, vielleicht viel schneller sehe und sagen kann, ich kann hier 20 Prozent meiner ganzen Rechenzeit sparen, wenn ich ein Feature vielleicht etwas verbessere. Ich habe lange zum Beispiel in vielen Unternehmen lange keine Profiler mehr gesehen. Früher war das Standard, einen Profiler zu nutzen und zu gucken, wo...

verbraucht ein Stück Software, richtig viel Rechenzeit und heute ist es eigentlich egal, weil das Ganze horizontal skaliert.

Ich höre oder ich verstehe jetzt ganz klar messen wir brauchen eine Datengrundlage, wo Verbrauch der viel Rechenlast was sind die Treiber also vielleicht auch eine gute Information in der Observability wie lange laufen die Systeme und zu welchem Zeitpunkt ist überhaupt interessant so ein System zu laufen also Testsysteme müssen wahrscheinlich nicht dann laufen wenn wir Office hours haben und die Entwickler dann irgendwie sowieso zu Hause sind es sei denn es laufen automatisierte Tests also dementsprechend kann man sehr viel wenn man gute Daten

hat, dann analysieren und dann gezielte Maßnahmen treiben. Also das wäre so das Fazit für mich.

Man

kann das aber auch nur ganz leichte Sachen machen. haben es bei einer anderen Stelle einfach gemacht. Du willst ja tagsüber viele Build-Agents haben, damit die Pipelines schnell laufen, damit die Leute, die die Code einchecken, relativ schnell Feedback kriegen, ob die Änderungen, die sie gemacht haben, erfolgreich waren oder nicht. Das heißt, du willst viele Build-Agents haben, aber nachts brauchst du die nicht. Also wenn du sagst, wir haben einfach irgendwo eingetragen, das kannst du meistens, also hoffentlich Infrastructure as Code in dem Skript, aber zur Not auch in der Konsole, dass die ganzen Build-Agents morgens acht hochgefahren werden.

und abends acht runtergefahren werden. Das ist einfach schon mal eine Halbierung jeden Tag an der Anzahl der Stunden, die diese Systeme laufen. Wie ich gesagt habe, in modernen Server verbrauchen im Idle ungefähr 20 Prozent ihres Stroms. Also das ist schon einfach zu sagen, wir machen die nachts aus. Und das bringt ja was, wenn in der Cloud laufen, weil in der Cloud dann andere Unternehmen oder andere Teile des eigenen Unternehmen die gleichen Server nachts benutzen können. Aber es gibt eben, und das wollte ich ganz am Anfang habe ich vergessen zu sagen, weil ich meinte, das ist

spannend.

Nur die halbe Wahrheit. Es gibt natürlich aus kommerziellen Gründen ganz viele Verträge mit Cloud-Provider, wo es Commitments geht. Wo ich sage, ich committiere mich auf eine bestimmte Rechnung, damit ich die in Summe billiger kriege, was die Cloud-Provider natürlich gerne machen für die Planbarkeit. Also das ist auch alles nicht schwarz-weiß, das ist auch relativ grau an der Stelle.

Aber ich glaube nach wie vor ein wichtiges Thema und es lohnt sich da eine Analyse mal zu fahren oder auch mal bei sich selbst zu schauen, wie optimal sind wir da aufgestellt. Jetzt gegen Ende noch mal eine persönliche Sache zu dir. Ich fand das in unserem Vorgespräch ganz interessant. Ich hatte mir aufgeschrieben, du bist CTO und Häft of Technologies und dir war es besonders wichtig auch zu sagen, dass du im Kundenkontakt bist, dass du wirklich dort als Consultant auch unterwegs bist, dass du dort auch wirken möchtest. Wie war denn oder

Wie balancierst du das denn aus, diese A auf der einen Seite, diese hochstrategische Rolle und auf der anderen Seite aber noch da quasi an der Basis auch in der Technik drin zu sein? Wie schwierig ist das für dich? Wie hast du das bisher gemeistert?

Es hat sich über die Jahre natürlich gewandelt. Ich würde mal sagen, Sache, an der ich viel gesehen habe, einfach, als Beratungsfirma ist man natürlich immer dabei, auch neue Kunden zu akquirieren. Und das ist so ein, in meinem Fall würde ich mal sagen, so ein positiver Reinforcement Loop, wenn man halt noch relativ technisch ist. Es ist halt oft auch sinnvoll, in frühen Gesprächen mit Kunden dabei zu sein, zu verstehen, was ihre Probleme sind.

weil man ein Verständnis dafür hat, welche Technologien helfen können, aber auch gleichzeitig die existierende Systemlandschaft bei den Kunden grob zu verstehen. Das das hat mir schon geholfen, sehr guten breiten Blick zu kriegen. die viele Erstgespräche, Zweitgespräche mit Kunden, zu sehen, was haben die eigentlich, was sind die Probleme, die die Kunden wirklich umtreiben. Ich erinnere mich auch an einen, den würden alle kennen, großen Kunden, wo ich mit der CTO gesprochen habe, auch über die Möglichkeit von Gen.AI. Und die sagte mir,

würde ich gerne machen, aber ich habe ein Budget und habe ganz andere Probleme, die ich erstmal wirklich lösen muss. Und du kannst mir jetzt gerne erzählen, you're missing out. Und ich habe es ja gar nicht gemacht. Sie hat das schon so vorweggenommen. You're missing out und du verpasst hier die Chance deines Lebens. Sie sagte, ich habe das alles verstanden, aber ich habe ganz andere Prioritäten und ich bin mir sicher, dass ich das richtig mache. Also einfach so dafür einen Blick zu kriegen. was ist auf der einen Seite das, wo gerade auf Twitter, LinkedIn, man hat ja in der Einung, es gibt nichts anderes mehr als Gen.Ai, aber das abgleichen zu können mit einem relativ breiten Blick darüber, was die

Leute in den Unternehmen und ich war ja zum Schluss auch für ganz Europa verantwortlich, also nicht nur in Deutschland, auch in anderen Ländern, denen wir waren oder sind. Was bewegt die eigentlich wirklich? Das hat geholfen und auch zu sehen, was gibt es für ein Match zwischen den Technologien auf der einen Seite und den tatsächlichen Business Problemen, ich auf der einen Seite, aber auch dem Potenzial, was die Kunden vielleicht heben könnten, wo die Technologien helfen. Der zweite und die zweite Hälfte davon war aber auch

dass ich durch meine Rolle in einer gewissen Luxusposition war und es mir möglich war, mich selbst immer wieder auch mal, es war auch gewünscht von der Firma, tatsächlich muss man sagen, auf einzelne spezielle Kundenprojekte wirklich selber zu staffen, wie man sagt, also dass ich daran dann mitarbeite, direkt bei den Kunden und ich habe mir die natürlich dann mit einer gewissen strategischen Brille ausgesucht. Ich habe dieses Jahr für ein großes Pharmaunternehmen eine Softwarelösung mitgebaut, wo wir eine

eine Custom Extension, keine MCP, also kein Model Context Protocol Server, sondern eine wirkliche echte GitHub Copilot Extension geschrieben haben, die Daten von Backstage einzubinden. Das habe ich natürlich ganz bewusst gewählt, ich habe, ich will jetzt einfach mal gucken, wie erweitert man das und ich bin mir relativ bewusst, wie viele Probleme, Sicherheitsprobleme MCP verursachen kann und dachte, okay, aber es gibt ja noch eine Copilot Extension, aber ist die jetzt wirklich so schlecht, dass man die nicht benutzen kann und alle müssen MCP benutzen und das ich schon die Möglichkeit hatte, mir ganz gezielt immer wieder

konkrete Arbeiten rauszusuchen. man ein bisschen am Ball geblieben ist, wenn man die Technologien kann, kann man in so einem Team auch produktiv mitarbeiten. Man bekommt dann eben auch ein Gefühl dafür, was ist wirklich Hype und was funktioniert tatsächlich. Wir hatten ganz am Anfang darüber gesprochen, was war der letzte Code, den ich geschrieben habe. Ich müsste da eigentlich einen Artikel überschreiben, ich bin noch nicht zu gekommen. Ich hoffe mal, schaffe das, bevor die Information veraltet ist. Ich hatte ja gesagt, dass ich an dem Open Source-Projekt gearbeitet habe. Ich habe da tatsächlich aber auch mal ein Experiment gemacht und habe das wirklich in

Okay.

WindSurf mit Sonnet, also mit dem Claude Sonnet 3.7 bauen lassen. Ich hatte schon eine Anbindung an das API von GitHub und ich brauchte eine Anbindung an das API von GitLab. Also ein Klassikfall, aber in Swift, Programmiersprache, die jetzt nicht so verbreitet ist, nicht unverbreitet, nicht so verbreitet und habe das da mal experimentiert und dann konnte man schon sehen, ja, das hat sich nicht von selbst geschrieben, sagen wir es mal so. Und ich habe als erfahrener Entwickler eben auch einige Stellen gesehen, wo ich gesagt habe,

Das ist nicht wirklich gut, was hier passiert ist. Also es gab so eine Stelle, in Swift gibt es Optionals, also es war ein Optional String. Der generierte Code hat das nicht mitbekommen, hat nur ein String übergeben. Dann gab es einen Compiler-Fehler, natürlich, weil der String optional sein konnte. Ich habe den Compiler-Fehler einfach wieder an die KI gegeben, zu gucken, wie läuft denn sowas eigentlich? Was die KI gemacht hat, hat immer mit so einem Fragezeichenoperator gesagt, ach, wenn das Ding leer ist, mach mal ein Leerstring rein.

zu sehen, okay, ich muss das eigentlich wirklich ordentlich behandeln. Natürlich hat der Code funktioniert zunächst, natürlich hat es kompiliert, natürlich habe ich da nichts selber geschrieben. Ich habe es aber trotzdem hinterher von Hand korrigiert, weil ich genau weiß, dass ich mich selber in zwei, Monaten ärgere, wenn dadurch ein Bug aufgetreten ist an der anderen Stelle.

Ja, also das ist definitiv ein Skillset, was wir, glaube ich, auf allen Ebenen brauchen. Also das, was wir präsentiert bekommen. egal, ob es jetzt Code ist von einer KI oder irgendwelche Vorschläge in die Technologie, solltest du investieren. Wir müssen abschätzen können. Also wir müssen definitiv innerhalb einer kurzen Zeit ein Gefühl dafür bekommen, ist das was, was wirklich interessierter interessant ist, was uns dann wirklich weiterhilft und wollen wir da rein investieren oder nicht? Weil das Angebot auf dem Markt, also auch in den sozialen Medien, ist ja wirklich erschlagend und da knüpft auch mal

nächste Frage darauf an, wie erkennst du denn eine Technologie, wo sich es lohnt? Das ist jetzt ein Ding, das sollte ich mir näher angucken. meine bei Gen.Ai, hast ja kurz die Historie gesagt, das ist so ein bisschen der der Wink mit dem Zaunfall, also da haben das dann irgendwann alle gemerkt, aber es gibt natürlich dann auch ganz viele interessante Sachen, die jetzt nicht mit so einer Schlagkraft reinkommen, aber die man erkennen sollte und die man einfach mal im Fokus behält, also die auch auf euren Techradar und solche Geschichten nimmt. Wie erkennst du das?

Ja, ist der gleiche Luxus, ich hatte, dadurch, ich bei einer Beratungsfirma war. Und in der Rolle war die eben auch für einen Überblick verantwortlich. Du bekommst dadurch automatischen Überblick. Wenn ich jetzt ein CIO oder ein CTO von einer Firma wäre und ich hätte in meiner Abteilung, weiß ich nicht, 2000 Leute, dann hätte ich den Luxus nicht in der Form. Ich hätte auch ganz andere Sachen, die ich lösen müsste. Die Frage kann ich deswegen nicht so gut beantworten. Wie erkennt man neue Technologien? Auch da muss ich sagen,

Für ein Beratungsunternehmen ist es natürlich in gewisser Hinsicht offensichtlich, dass wenn der Markt über eine Technologie spricht, du auch darüber sprechen musst. Also es ist einfach, man kann sich dem nicht verschließen einfach. Wir haben es größtenteils gemacht bei den Blockchain Technologien, aber auch da, wir haben tatsächlich für ein großes Energiekonsortium eine Blockchain Lösung gebaut, obwohl eigentlich alle nicht so sicher waren, ob es funktionieren, also ob es wirklich sinnhaft ist oder nicht. Aber da haben wir uns wirklich sehr, sehr bedeckt gehalten, weil wir schon

wenig Substanz gesehen haben. Aber an vielen Sachen ist die Frage gar nicht, ist es hundertprozentig besser, wenn du in einem Beratungsniveau arbeitest, musst du dich mit den Sachen, die gerade diskutiert werden, weil die Kunden ja auch wissen wollen, was macht es aus? Wo es andersherum gut funktioniert, da hast du den Technology Radar angesprochen. Ich habe ja bei ThoughtWorks aufgehört, den werde ich mal weiterhin lesen. Im Moment, weiß, dass gerade diese Woche wird die nächste Ausgabe beschrieben oder produziert.

Da ist natürlich eine ganz andere Herangehensweise. Da ist so ein Bottom-Up-Approach, dass einfach gefragt wird, was habt ihr gesehen, was funktioniert und solche Sachen. Es sei nicht die Frage, woher wusstest du, dass Continuous Delivery funktioniert. Es war ja eher, wir haben was gemacht aus der Not heraus und wussten daher, dass es funktioniert, weil es ja aus der Praxis entstanden ist.

Da kann man eigentlich nur hoffen, man vielleicht ein gutes Netzwerk hat, dass man seinen Feed auf LinkedIn oder in den anderen sozialen Medien mit Augenmaß liest, vielleicht die richtigen Podcasts findet. ich finde auch, also man muss da nicht unendlich viele Stunden rein investieren. Das ist bisschen Geschmacksfrage, ich zum Beispiel, um mal ein bisschen positive Werbung zu machen, also Dave Farley, ich finde dieses Modern Software Engineering Podcast, oder es ist ja ein YouTube Channel, den finde ich richtig gut.

Sehr gut, werden wir auf jeden Fall aufnehmen in die Show Notes. Und ich glaube, ist auch das Ausschlaggebende aus meiner Sicht, in der Szene drin zu sein. Einfach auch mal vielleicht nicht nur LinkedIn, sondern auch irgendwelchen Reddit-Posts ein bisschen tiefer einzusteigen, auch mal zu schauen, was trendet gerade auf GitHub. Also was sind diese Sachen, womit beschäftigen sich aktuell die Leute? Und auch wenn da ganz viel Geschwindigkeitsdruck auch mit dabei ist, oft brauchen solche Sachen dann doch noch ein bisschen.

bis sie dann wirklich dort sind und man kann sie beobachten und dafür ist mit Sicherheit der Tech Radar auch ein sehr guter Indikator. hattest eben schon gesagt, du hast Thoughtworks verlassen. Nun fragen sich wahrscheinlich einige deiner Leser oder Fans auch, wie geht es weiter? Hast du schon eine Richtung? Möchtest du das hier auf dem Podcast teilen? Was sind so deine nächsten Schritte in die Zukunft?

Also ich kann die ganz ehrliche Antwort ist tatsächlich, dass ich noch gar nicht hundertprozentig sicher bin, was ich tun werde. Ich habe mir jetzt tatsächlich erst mal in den ausgehenden Sommermonaten eine kleine Auszeit gegönnt und bin relativ offen für verschiedene Sachen. Also ich kann mir verschiedene Dinge vorstellen, aber auf jeden Fall bin ich jemand, der im Laufe der Karriere immer wieder die Möglichkeit gehabt hätte, wir haben ja darüber gesprochen, wie man aktuell bleibt, die Möglichkeit gehabt hätte zu sagen, ich lasse die Technologie hinter mir. Ganz viele Leute, in

großen Konzernen, Beratungsfirmen, eine Führungsprodame haben ja einen technischen Hintergrund, aber haben dann zum letzten Mal vor zehn Jahren Code geschrieben und die die Guten von den Leuten wissen, dass ihr Wissen veraltet ist und kommen nicht mehr in Meetings rein und sagen, das muss aber so gemacht werden, weil so habe ich das gelernt. Also ich erinnere mich an einen Fall, da durfte nichts hardcoded werden, weil die Person zum letzten Mal wirklich große C++-Systeme programmiert hat und wir haben versucht, das war ein Ruby-System, es ist egal, ob ich es in der Konfigurationsdatei ändere.

und das durch die Pipeline schicke oder ob ich es im Source Code ändere, das ist genau der gleiche Aufwand. Es macht null Unterschied. Die Möglichkeit habe ich immer ausgelassen und da bin ich auch ziemlich sicher, dass ich dem treu bleiben werde. Das nächste, was ich machen werde, ist schon eine Rolle, die stark technologielastig sein wird. Vielleicht sogar technologielastiger als die Rolle, die ich zuletzt gemacht habe.

Hört sich auf jeden Fall spannend an. Ich werde es weiterverfolgen auf LinkedIn oder wo auch immer. Wo kann man denn am besten von dir lesen oder dich kontaktieren? Was sind denn die Links, wir teilen möchten, wenn jemand auf dich zukommen will oder von diesen Papern oder Blogposts, gesprochen hast? Wo finde ich die am besten?

Also ich muss wirklich sagen, LinkedIn ist an der Stelle die beste Wahl. Ich habe immer noch eine eigene Website, aber ich habe eigentlich alle Posts, die ich früher auf die Website geschrieben habe, die habe ich auf LinkedIn gepostet, weil es einfach besser erreichbar ist. Ich weiß, es ist sehr, sehr noisy, ist auf LinkedIn, aber andererseits, wie viele Leute haben noch einen RSS-Reader installiert und kuratieren eine Liste von RSS-Feeds? Also da muss man dann einfach wirklich sagen, da haben wir alle als Industrie so bisschen gesprochen und ich würde da wirklich LinkedIn sagen und von da aus...

Wenn es was gibt, weiter verzweigen. Aber ich bin jetzt auch nicht jemand, der jeden Tag zwei Posts abschickt.

Alles klar. Erik, es hat mir super viel Spaß gemacht. Also wir haben jetzt hier anderthalb Stunden geschafft. Also danke, dass du dein Wissen geteilt hast. Für deine Pläne für die Zukunft wünsche ich natürlich alles Gute und danke, dass du im Podcast warst.

Vielen Dank für die Einladung, hat mir echt Spaß gemacht. Fühlte sich für mich in einem spannenden Gespräch an.

Sehr schön. Alle anderen bitte teilt auch gerne, wie ihr es fand. Schreibt es in die Kommentare. Denkt dran auch zu liken und auch zu followen, dass die Community wachsen kann vom Beyond Code Podcast. Und bis dahin wünsche euch alles Gute und bis zum nächsten Episode. Bis dann. Ciao.