# AI Coding Myths: Strategic Realities For Software Delivery

**Podcast:** INNOQ Podcast
**Published:** 2026-05-25

## Transcript

Hallo und herzlich willkommen zu einer neuen Folge des InnoQ-Podcasts.
Heute mit Gerrit und Daniel zum Thema der mythische Mann-Monat bzw.
der mythische Bot-Monat.
Bevor ich loslege, vielleicht nochmal Hallo Gerrit, Hallo Daniel.
Hallo Sven.
Wie geht's euch?
Hallo.
Gut.
Ja, wunderbar.
Was macht ihr?
Ich weiß nicht, man muss euch wahrscheinlich nicht mehr vorstellen.
Aber vielleicht sagt noch mal einen Satz zu euch jenseits des Senior-Konsultentums.
Gerhard, geht los.
Ich soll anfangen?
Ja, meinen Namen hast du schon genannt.
Ich bin seit gefühlten 100 Jahren in der IT unterwegs.
Und das, worauf wir uns heute beziehen, begleitet mich seitdem.
Und ich bin mal ganz in...
Ganz gespannt, wie es uns gelingt, jetzt die Thesen von Fred Brooks, die ja auch schon älter sind als ich, mit dem aktuellen Thema zusammenzubringen.
Ja, Daniel.
Ja, was ich ganz spannend finde, ich glaube, was Gerrit und ich und mich verbindet, dass wir beide eher so einen interdisziplinären Hintergrund haben und nicht reine Informatiker oder sowas sind.
Und als solcher habe ich halt auch Ja, vor einiger Zeit angefangen mal zu schauen, was eigentlich zum Beispiel die Kognitionspsychologie uns darüber sagen kann, wie man mit AI-Tools ums gehen sollte oder auch nicht.
Und Berit hat glaube ich noch mehr so die soziologische Perspektive dazu auch.
Ergänzt sich glaube ich ganz gut.
Ich bin auf jeden Fall gespannt.
Also vielleicht für alle jüngeren Teilnehmer, die nicht so alt sind wie wir.
Wir sind ja schon...
Oh je.
Sollte man gar nicht sagen.
Nee, nee, sollte man gar nicht sagen.
Aber auf jeden Fall älter als wir ist dieses Buch, der mythische Mann-Monat, geschrieben 1975 oder 76 war es von Fred Brooks.
Und der hat so ein paar Wahrheiten der Softwareentwicklung dort beschrieben.
Als er da an der IBM, ich glaube an der Z...
Series oder sowas.
Irgendwas IBM, irgendeine IBM-Software.
Auf jeden Fall lustigerweise, als ich angefangen habe zu studieren, kam die 25 oder 20 Jahre, nee, war viel früher, als ich angefangen habe zu studieren, fällt mir da ein, kam diese 20-Jahre-Edition raus und da war plötzlich so, also die Meinung war, naja, eigentlich hat sich daran nichts geändert.
Und jetzt sind wir wieder.
Es sind wir sozusagen 30 Jahre weiter und es sagen ja einige Leute, dass mit AI sich natürlich alles ändert und alles auf den Kopf gestellt.
Und ja, wir wollen einfach nochmal durch ein paar Thesen durchgehen.
Wir werden nicht alles schaffen, aber wir diskutieren auf jeden Fall mal ein paar.
Also Klassiker sind überhaupt der mythische Mannmonat.
No Silver Bullets, davon habt ihr wahrscheinlich schon mal gehört, konzeptionelle Integrität.
Ich würde vielleicht mit einem der letzten Punkte anfangen und zwar Reduzierung der Kosten durch Commercial-off-the-shelf-Software, weil da gab es die letzten Wochen lustige Diskussionen.
Man könnte auch sagen, dass Software-as-a-Service Ist ja auch im Grunde genommen Commercial off the shelf und da heißt es ja jetzt ein paar Wochen, oh, die SARS-Apokalypse kommt.
Die Aktien haben alle, wie wir Börsenexperten sagen, nachgegeben, was diese SARS-Firmen angeht.
Ist alles vorbei, SARS.
Ihr könnt alle einpacken, weil wir statt zu kaufen, wird gewanschottet sozusagen.
Genau, sorry, das habe ich schon ein bisschen vorweggenommen.
Also was hat überhaupt Fred Brooks gesagt?
Fred Brooks erwähnt entsprechend der Make-or-Buy-Abwägung, Software überhaupt nicht selbst zu entwickeln, sondern nach Möglichkeit einfach Standardsoftware einzusetzen.
Und ich denke, die Diskussionen, die haben wir auch.
Make-or-Buy, was ist so eure Meinung zur SARS-Apokalypse?
Wird es agentic coding dazu führen, dass wir...
keine Software mehr einkaufen.
Gerrit, fang du mal an.
Also ich denke nicht, dass das das Resultat ist, dass überhaupt keine Software mehr gekauft wird.
Ich denke aber, dass in etlichen Bereichen, in denen die Entscheidung bisher so an der Grenze war und dann vielleicht zum Bei gekippt ist, heute anders ausfallen wird und man tendenziell häufiger dann sagt, okay, dann bauen wir doch was selbst, weil das Customizing unter Umständen teurer wäre als die naive Annahme einer weibgecodeten Eigenlösung.
Ob das klug ist oder nicht, ist noch eine andere Geschichte, aber ich wage zu behaupten, dass das häufiger passieren wird.
Ja, Daniel.
Also wenn man sich LinkedIn anguckt, dann macht das ja jetzt eigentlich fast jeder, die SaaS-Software nicht mehr einzusetzen und stattdessen selbst zu schreiben, weil es irgendwie nur noch eine Woche dauert, woran diese Firmen irgendwie jahrelang gesessen haben, das umzusetzen.
Das klingt auch erstmal super, so für einfache, gut verstandene Probleme.
Kann vielleicht so ein technischer Gründer schnell was selber bauen, anstatt dann so ein SaaS-Abo sich zu schießen?
Aber irgendwie liest man dann auch nie, was danach passiert, oder?
Also Betrieb, Wartung, weiß ich nicht, neue Features, Edge Cases, die man noch gar nicht kannte, weil die Domäne doch komplizierter ist.
Und in diesen SaaS-Anwendungen steckt halt so viel Erfahrung auch über die Domäne drin.
Malseits davon, dass man es nicht betreiben muss, dass ich glaube, es wird zwar passieren, dass das jetzt viele machen, aber wahrscheinlich merken sie auch irgendwann, dass das keine gute Idee war.
Ja, ich kenne also einer meiner Podcast-Kollegen bei Case, der Heinrich Hartmann, der ist ja Site Reliability Engineer und der sagt halt, also wann immer man den Betrieb auslagern kann, sollte man es tun.
Also da steckt schon ziemlich viel dahinter zu sagen, ich betreibe das nicht.
Ja, wobei das sind Dinge, die würde ich nicht unbedingt vermischen.
Bei dem Betrieb auslagern, das sehe ich teilweise ein bisschen anders.
Da sehe ich die Kritikalität eher so in dem Fokus, ich lagere das aus, bei dem ich sagen kann, wenn das ausfällt, weil der Betrieb, der ausgelagert und nicht verfügbar ist, bin ich trotzdem noch handlungsfähig.
Aber was ich prinzipiell nicht auslagern würde, sind die Systeme, an denen die Existenz meines Unternehmens hängt.
Also ich halte es zum Beispiel für eine denkbar dumme Entscheidung.
beispielsweise Authentifizierung, Autorisierung auszulagern.
Das kann man systemtechnisch auch wunderbar durchargumentieren, warum das nicht klug ist.
Aber bei dem AI-Thema halte ich tatsächlich den Betrieb gar nicht so sehr für das Kritische, sondern ich denke da eher an so Dinge wie, wie viele Menschen auf dieser Welt benutzen Software wie Word.
Jetzt kann ich da naiv rangehen und sagen, eine Software wie Word ist erstmal naiv gesehen relativ einfach zu verstehen.
Das Vibe-code ich mir mal eben.
Da kommt dann auch eine Textverarbeitung raus, mit der ich arbeiten kann.
Die Challenge ist aber, bei Software wie Word, und da kann man auch noch andere Produkte dann hernehmen, liegt es.
Der große Wert und das, was quasi das Zeug funktionsfähig macht, nicht darin, dass ich eine Benutzeroberfläche habe, wo ich Text eingeben kann und am Ende wird eine Datei gespeichert, sondern da liegt der große Wert darin, dass das, was gespeichert wird, austauschfähig ist mit anderen Leuten.
Ich kann so eine Wirt-Datei nehmen, kann die dir schicken, Sven, oder dir, Daniel, und ihr seht die Wirt-Datei genauso, wie die bei mir angezeigt wird.
Kann man jetzt bei Wirt immer drüber...
streiten, ob das so ist oder so, aber prinzipiell, wenn ich einen Text fett gemacht habe, wird er bei euch auch fett angezeigt.
Das funktioniert ziemlich zuverlässig und spannend ist, es gab mal viel, viel mehr solche Textverarbeitungsprogramme.
Der Markt hat sich konsolidiert.
Warum?
Weil der Austausch das Schwierige ist.
Wenn wir jetzt mit 300 Word-Varianten loslegen, jeder Weib codet sich sein eigenes Word, werden wir genau an diesem Austausch scheitern.
Und das ist das.
warum das aus meiner Sicht eine irre Hürde gibt, sowas nicht off the shelf zu kaufen und nicht von einzelnen Unternehmen entwickeln zu lassen, sondern zu sagen, ich weibcode mir das mal eben.
Und ich möchte an der Stelle nochmal sagen, also ich benutze natürlich LibreOffice, ich benutze nicht Word, aber das Austauschformat ist häufig trotzdem genau das.
Ich würde auf jeden Fall mal auf einen Punkt von Daniel zurückkommen.
Und zwar, du hast ja gesagt, ah ja, dann muss ich das weiterentwickeln und ich habe irgendwelche Edge-Cases, an die keiner gedacht hat.
Ich hatte nämlich neulich die Diskussion, ein Kunde von uns, für die ist total wichtig, also ihre Logistik-Sparte ist total wichtig und da haben die natürlich Routenplanung, Software und jetzt ist die Frage, baue ich mir die Routenplanungssoftware selbst.
Und da war ein Argument, ja klar, weil, also nicht von der Firma, ja klar, das Weltwissen weiß ja, wie man Routenplanung macht.
Und da denke ich, ja, also vielleicht, aber nehmen wir an, das Weltwissen würde wirklich wissen, wie man Routenplanung macht.
Es müsste das ja auch korrekt implementieren.
Irgendjemand müsste entscheiden, dass das korrekt ist.
Weil wenn ich einen Bug habe und es funktioniert nicht so, was macht man dann?
Also dann hat man echt gelost.
Von daher sehe ich das halt, also ich sehe es definitiv nicht so.
Eine Sache, die dieselbe Person gesagt hat, wo ich meine Meinung tatsächlich geändert habe, war Domain-Know-how.
Und da würde mich auch eure Meinung mal dazu interessieren.
Wenn ich jetzt SAP nehme und SAP macht ERP-Software und ich könnte jetzt 3 Millionen Zeilen konfigurieren oder ich könnte 10 Millionen Zeilen-Code oder 20 Millionen Zeilen-Code selbst schreiben, da ist die Frage, kennen nicht Firmen, die SAP ERP oder CRM Software nutzen, kennen die nicht auch ihre Prozesse so gut, dass sie das selber machen können?
Also sie haben das Domänen-Know-how, weil es ja ihre Problemdomäne ist?
Ich glaube, da muss man drüber nachdenken, mit welcher Idee man SAP einführt.
Also das eine ist, ich kann SAP einführen und ich passe meine Unternehmensprozesse an die SAP-Standards an.
In dem Moment habe ich das Domänen-Know-how nicht.
In dem Moment profitiere ich aber von einer Standardisierung und sage, die funktioniert für so viele Unternehmen.
Da kann ich auch davon profitieren.
Und ich sage, ich will mir über bestimmte Planungsprozesse gar keine Gedanken machen, wie die auszugestalten sind.
Das überlasse ich anderen und bezahle im Prinzip dafür, dass ich das Nachdenken über Prozessabläufe externalisiere.
die für mich jetzt nicht entscheidend sind.
Da geht es jetzt um Prozesse, die nicht mein Unique Selling Point als Unternehmen sind.
Das andere ist, es gibt viele Unternehmen, die kaufen SAP und benutzen SAP quasi nur als Programmierplattform, um ihre eigenen Prozesse darauf umzusetzen.
Da würde ich dann sagen, eigentlich ist das Tool, mit dem die das machen, relativ egal.
Da tauschen wir dann SAP gegen, was weiß ich, Java, .NET, you name it aus.
Und wie der Code dazu entsteht, Mein Gott, das ist egal.
Aber die machen im Prinzip schon genau das, die das sehr, sehr steuerlich ins Customizing von SAP gehen.
Okay.
Ja, würde ich sagen, schließen wir mal diesen Punkt.
Also ich glaube, wir können uns darauf einigen, an den Punkten, wo man heute vielleicht sagen würde, wir machen eher bei, kippen wir in Zukunft.
tendenziell mehr auf Make, aber vermutlich bleibt das so bis auf, also die Aussage bleibt so bis auf dieses Randgebiet.
Also wie gesagt, ich vermute, dass es eher so bei denen ist, die auf der Kippe standen, die früher eher tendenziell in Richtung Beige kippt sind, weil man gesagt hat, wer so eine Standardlösung kauft, kann nichts falsch machen.
Das wird häufiger in Richtung Make kippen, aber substanziell glaube ich.
Also ich habe gedacht, ich hätte das gesagt.
Ich hatte es ein bisschen anders verstanden, aber dann haben wir es nochmal geklärt.
Ja, okay.
Gut.
So, jetzt würde ich mal auf die Klassiker kommen und zwar Einer der berühmtesten Sätze aus dem Buch ist ja No Silver Bullets, keine Silberkugeln, also die Silberkugeln, die den Werwolf töten.
Fedbook sagt, es gibt keine einzige Entwicklung, weder technologisch noch bei den Techniken des Managements, die für sich allein versprechen können, im Laufe von zehn Jahren wenigstens eine Größenordnung, das Zehnfache an Verbesserungen bei Produktivität.
Zuverlässigkeit oder Einfachkeit zu garantieren.
Da würde ich sagen, also die Versprechen sind alle, wir sind jetzt, wir sind alle 10x, oder?
Ja, aber da sind ja drei entscheidende Worte drin, für sich allein.
Und der Brooks hat ja nie behauptet, dass es einzelne Verbesserungen halt nichts bringen.
Und es kann ja theoretisch sogar sein, dass AI irgendwie bei der Implementierung uns eine zehnfache Verbesserung gibt.
oder Produktitätssteigerung.
Aber das heißt halt nicht, dass wir zehnmal schneller Software ausliefern, weil dann halt die Flaschenhälse einfach nur woanders sind, wenn wir jetzt schneller Code schreiben.
Zum Beispiel im Requirements Engineering, Domänenverständnis, User Research oder auch die ganzen organisatorischen Entscheidungsprozesse, die werden dann halt zum dominanten Flaschenhals.
Und deswegen finde ich, dass agentische Entwicklung eigentlich das beste empirische Argument für Brooks' These ist.
Dass es also immer noch gilt.
Außerdem haben wir jetzt immer nur über Produktivität gesprochen.
Und das hatte ich auch immer nur so im Kopf, wenn man über die Silver Bullet spricht von Brooks.
Aber du hast es ja gerade nochmal gesagt, es ging auch um Zuverlässigkeit und Einfachheit.
Und zumindest bei Zuverlässigkeit sagt die Datenlage ja zum Beispiel diese DORA-Studie, die nimmt ab, seitdem die Leute sehr viel AI einsetzen für Code-Generierung.
Und ich glaube auch, dass die AI nicht unbedingt den einfachsten Code generiert.
Das würde ich auch unterschreiben.
Also gerade das Thema Einfachheit ist halt bei einem System, das intern nicht auf Determinismus basiert, etwas, das kriegen wir nicht gewährleistet.
Also ein storastisches System ist notwendigerweise in der Wahrnehmung dessen, der es beobachtet, immer komplizierter.
komplexer vielleicht als ein System, das sich deterministisch verhält.
Also da glaube ich nicht, dass uns in Richtung Einfachheit was geholfen ist.
Es ist leichter, Code zu erzeugen oder wie das jemand so schön gesagt hat, es ist viel einfacher geworden, schlechte Software zu generieren.
Das würde ich sagen, ja, das ist einfacher, aber das, was als Ergebnis rauskommt, ist nicht unbedingt einfacher.
Und was ich Ich glaube, was Daniel angefangen hat, das Erste, was du gesagt hast, diesen Fokus auf, es gibt keine einzelne Methodik, Vorgehensweise, die uns irgendwie diesen Boost gibt.
Das ist ja eigentlich was, was eigentlich kann man sagen, die letzten 40 Jahre kontinuierlich bestätigt wird.
Und es gibt immer dieses mit Augenzwinkern zitierte Solow-Paradox.
You can see computers everywhere but in the productivity statistics.
Und dann kann man natürlich sagen, ja, also so richtig viel gewonnen an Produktivität haben wir in den Industrienationen in den letzten 40 Jahren nicht mehr.
Und dann kann man sich fragen, warum eigentlich nicht?
Und wenn man als Kanbanist mal loslegt und das misst, stellt man fest, naja, wir können jetzt zwar mit diversen Methoden, Tools und Frameworks im Arbeitsprozess nochmal irgendwie 10% gewinnen oder so.
Und 10% sind schon viel.
Aber wenn man sich anguckt, eine Aufgabe, die durch eine Organisation durchläuft, die braucht, was weiß ich, halt 100 Kalendertage.
Und nur drei von diesen 100 Kalendertagen wird an dem Ding gearbeitet.
Und 97 von diesen 100 Kalendertagen wartet es auf die nächste Entscheidung.
Und jetzt kann ich an den 3 Prozent 10 Prozent mehr machen.
Das heißt, ich reduziere diese 3 Prozent im Anteil auf 2,7 Prozent.
Aber die 97 Prozent, die wir auf Entscheidungen warten, werden dadurch überhaupt nicht angefasst.
Das heißt, selbst wenn es uns gelingt, im Programmieren produktiver zu werden, was an der einen oder anderen Stelle durchaus sein kann, wird das nach außen überhaupt nicht sichtbar werden.
Also ich meine, du sprichst ja...
Du sprichst ja Value Stream Mapping an, also dass man halt guckt, wir werden nicht schneller dadurch, dass wir schneller arbeiten, sondern wir werden schneller, indem wir weniger warten.
Wir gucken auf die Stellen, wo nicht gearbeitet wird, sondern wo gewartet wird.
Warum hat uns eigentlich Value Stream Mapping nicht weitergebracht?
Also eigentlich müssen wir ja alle Value Stream Mapping machen, um schneller zu werden.
Ich glaube, das hat uns weitergebracht, aber es ist halt anstrengend, das anzuwenden, deswegen macht es keiner und die meisten Unternehmen sind gut genug, deswegen haben die keine Mieters zu machen.
Wenn ich mich auf einem Markt behaupten kann, als Unternehmen muss ich nicht besser werden.
Wozu?
Ich komme noch mal kurz auf Zuverlässigkeit und Einfachheit zurück.
Und zwar hatte ich letzte Woche eine lustige Diskussion, also war beim Kunden.
Wir haben natürlich über Agendic Software Engineering ziemlich intensiv diskutiert.
Und da sind wir auch auf das Thema Zuverlässigkeit gekommen.
Und zwar gab es Microsoft Windows Nutzer und die haben sich massiv beschwert, dass das neue Windows, ich weiß nicht was ist, 11, 12.
13, also auf jeden Fall das neue Windows, was mit großer Hilfe von Co-Pilot entwickelt wurde, im Grunde genommen unbenutzbar ist, also so haben die es gesagt, kannst du eigentlich nicht nutzen.
Das beste Beispiel dafür, dass man echt, dass man was tun muss.
Und ich frage mich halt, wird man was tun oder nicht?
Also das habt ihr ja auch so angesprochen.
Werden wir uns einfach daran gewöhnen, dass Software in Zukunft total krottig ist?
Also genauso wie das neue Windows?
Ich weiß nicht.
Grottiger geht immer, oder?
Also es gibt ja auch Stimmen, die sagen, dass in den letzten zehn Jahren die Software schon viel grottiger ist als die in den 90ern zum Beispiel.
Aber ich hoffe, dass wir uns nicht dran gewöhnen, sondern dass es irgendwann so schlimm ist, dass man dann eine Kehrtwende macht.
Also ich glaube, in anderen Bereichen haben wir uns da schon dran gewöhnt.
Wenn man sich so anguckt, zitiere jetzt mal jemanden ohne Namen zu nennen, was so die Filmindustrie und die Musikbranche so an Mainstream veröffentlicht, hat die Varianz abgenommen und die Durchschnittlichkeit ist jetzt nicht unbedingt nach oben getriftet, sondern tendenziell eher so in einem Mittelfeld geblieben.
Also jetzt mal einzelne Künstler und Künstlerinnen ausgenommen, aber so im Wenn man so den Mainstream anguckt, ist da so eine gewisse Gleichförmigkeit.
An die gewöhnt man sich natürlich.
Ich kann mich auch in die 90er erinnern, an Windows 3.1, dass 17 Mal am Tag abgestürzt ist, wo man dann so ein Hard Reset gebraucht hat.
Das waren auch keine tollen Zeiten.
Ob da jetzt wirklich so viel schlechter geworden ist, kann man diskutieren.
Ich kann mir vorstellen, dass da schon eine Gewöhnung einsetzt in Bezug auf Mittelmäßigkeit.
Nicht unbedingt auf, dass es alles schlecht ist, aber dass man sich mit bestimmten Dingen einfach zufrieden gibt und das halt einfach hinnimmt.
Kann ich mir gut vorstellen.
Ja, wir werden sehen.
Also ich hatte neulich, hatte ich noch gelesen, dass Claude Kurz netto 110 Bugs, neue Bugs jeden Tag produziert.
Also sie produziert auf ihrer GitHub, ich glaube bei GitHub sind die, werden jeden Tag 160 neue Bugs eingestellt und 50 werden gefixt.
Und die sind aktuell bei 6.500.
Also das ist natürlich jetzt auch wieder ein paar Tage her.
Naja, und da kommen auch Stimmen, dass einfach zu viele Klitsches sind, zu buggy und dass Leute halt keine Lust mehr so langsam bekommen, damit zu arbeiten.
Kann ich jetzt nicht so gut einschätzen, aber habe ich halt auch gedacht, okay, das hört sich nicht so gut an, was Zuverlässigkeit angeht.
Ich glaube, was man da nicht unterschätzen darf, ist halt, wir sind es gewohnt, dass Computersysteme sich deterministisch verhalten.
Darauf werden die Leute seit Informatik als Ausbildungszweig geschult.
Und mit genau dieser Idee, dieser Zuverlässigkeit, dieses Determinismus, gehen die Leute jetzt halt auch an diese Code-Generatoren ran.
Und die Tatsache, dass das halt gerade nicht zuverlässig ist und dass da halt Bugs passieren können, die der erzeugt, haben glaube ich viele Leute, die da Entscheidungen treffen in Bezug auf, ich setze es ein oder ich setze es nicht ein.
gar nicht so auf dem Schirm.
Dann kommt immer das Argument, ja, der Mensch macht ja auch Fehler.
Und dann kann ich sagen, ja, der Mensch macht auch Fehler.
Aber das Entscheidende ist, wenn ich mein Softwareentwicklungsteam habe und ich weiß, die eine Kollegin, die kann super Speicherverwaltung implementieren, der andere Kollege kann das weniger gut.
Dann kann ich ja bei der Aufgabenzuweisung und bei den Reviews schon sagen, Wen lasse ich es machen und wen lasse ich es reviewen?
Das heißt, ich kann im Laufe der Zeit eine gewisse Erwartung an das Verhalten der Leute entwickeln, wie die mit Dingen umgehen und was die gut machen und was sie nicht gut machen.
Die sind als Individuum immer noch, haben die eine Bandbreite, in der sie sich verhalten, aber ich kann mit einer validen Erwartung aus der Vergangenheit die Leute einplanen und ihnen auch Aufgaben geben.
Und das funktioniert ausreichend stabil, dass Unternehmen großartige Sachen auf die Welt bringen.
Jetzt haben wir diese Coding Agents, bei denen ich diese Erwartungen nicht entwickeln kann.
Weil die können halt zufällig, also ich kann die parametrisieren und alles, das ist unbenommen, aber die können halt trotzdem zufällig mal aus diesem Muster noch auf eine Weise ausbrechen, wie das ein Mensch nicht tun würde.
Also die Kollegin, die gut Speicherverwaltung kann, die vergisst das nicht einfach mal, dass sie das kann.
verhält sich halt dann wie jemand, der es nicht kann.
Das wird nicht passieren.
Der Coding-Agent kann aber so ein Verhalten zeigen.
Und das ist was, das muss ich an der Stelle, wenn wir über Zuverlässigkeit reden, und damit meine ich jetzt nicht nur die Zuverlässigkeit in der Ausführung von der Software, sondern auch die Zuverlässigkeit beim Erstellen einer Software, sowas müssen wir mitdenken.
Und dann brauche ich als Softwareentwickler plötzlich Management-Skills, weil das auszubalancieren und das hinzukriegen, das ist so der Core.
die Kernfähigkeit von allen Leuten, die Management machen.
Okay.
Ja.
Wir werden...
Ja, ich meine, bei Steve Jägi hat ja Gastown entwickelt und er sagt ja selbst, du bist halt der Bürgermeister von Gastown.
Okay, als Bürgermeister ist man unbedingt Manager, aber man muss trotzdem die Fäden in der Hand halten.
Okay.
Würde ich zum nächsten Punkt schwenken.
Und zwar, ah, eins meiner Lieblingspunkte bei jetzt in Zeiten von AI und zwar die Teergrube.
Also was sagt Fred Brooks?
Also ich paraphrasiere.
Also mein Neffe hat einen Prototypen am Samstagnachmittag programmiert.
Warum soll das bei euch Profis jetzt so teuer sein?
Das hört man jetzt relativ oft.
Also ich habe da mal irgendwas gewoneshottet, hat 37 Sekunden gedauert und es kann ja jetzt wirklich nicht mehr so weit sein, da ein ordentliches Produkt rauszumachen.
Also ich könnte regelmäßig darüber ausflippen, aber was sagt ihr denn dazu?
Daniel, willst du mal loslegen?
Ja, du hast ja schon gesagt, dass man das jetzt ziemlich häufig sieht.
Auch gerade wieder auf LinkedIn prominent Leute, die halt über das Wochenende irgendwie eine App entwickelt haben.
Und ich glaube, deshalb ist auch diese Tergrube von Brooks eigentlich heute noch relevanter denn je.
Bei Brooks waren es ja irgendwie, glaube ich, noch diese zwei Tüftler in der Garage, von denen er gesprochen hat, deren Geschwindigkeit man irgendwie bewundert hat.
Und heute ist halt der Unterschied, man kennt nicht nur die in der Garage, sondern man kann selber am eigenen Leib.
eigentlich spüren, wie schnell man mit Vibe-Coding eben neue Software erstellen kann.
Aber das sind dann eben, wie Brooks sagt, nur Programme und keine Programming-Products und schon gar keine Programming-System-Products.
Also dieser Referenzpunkt hat sich irgendwie total verschoben.
Jetzt hast du halt Leute, die haben keine Erfahrung in professioneller Softwareentwicklung, haben aber übers Wochenende eben so eine App gebaut.
Das heißt, die waren Noch nie selbst in dieser Tergrube der Softwareentwicklung in größeren Organisationen.
Und haben das nie kennengelernt, glauben jetzt aber zu wissen, wie Softwareentwicklungen funktionieren.
Wenn solche Leute dann jetzt Manager, Entscheider oder Product Owner werden, dann kann man sich natürlich fragen, wie groß wird da das Verständnis sein dafür, dass Entwicklungsteams länger brauchen.
Ich glaube, es wird ja jetzt weniger werden, als es bisher vielleicht schon der Fall war.
Das Verständnis wird weniger werden.
Das heißt, wir müssen mehr erklären, warum es länger dauert.
Ja, weil sie ja denken, wenn sie es selber ausprobiert haben, dann sind sie ja schon ganz nah dran und verstehen, wie es funktioniert.
Während sie vorher das nur von den Leuten in der Garage kennen, die Geschichte.
Aber wenn man das selbst gefühlt hat und glaubt man vielleicht noch mehr, man weiß, wie das funktioniert.
99 Prozent des Produkts dauert 99 Prozent der Zeit und das restliche eine Prozent dauert wieder 99 Prozent der Zeit oder so.
Aber du hast gerade erwähnt, also was muss man denn noch alles tun?
Also was sind denn die ganzen Dinge, die in so einer Organisation noch anfallen?
Also was ist überhaupt so ein Programming Systems Product?
im Vergleich zum Garagenprogramm.
Also was würdest du dem Manager, dem Vibe-codenden Manager erzählen?
Ich glaube, das war eigentlich so eine Matrix, oder?
Ja.
Mit vier Elementen.
Ja, so eine 2x2 Matrix.
Ein Programm, ein Programming-Product und auch ein Systems-Programm oder sowas.
Also bei dem Systems geht es ja darum, dass du eigentlich mehrere Systeme hast, die du integrieren musst zu deinem großen System.
Da sind natürlich viele Herausforderungen, die du bei so einem Garagenprodukt mit zwei Leuten machst, hast du einfach nicht.
Integration zwischen verschiedenen Systemen, Kommunikation zwischen diversen Teams und so weiter.
Und bei dem Product geht es dann eben um Markgreife eigentlich.
Das ist ein stabiler Betrieb und so weiter.
Und das sind alles Sachen, die erfährst du nicht, wenn du am Wochenende eine App paust.
Ja, ich habe mir noch dazu notiert, also Marktreife ist irgendwie getestet, integriert, dokumentiert, installierbar, erweiterbar, betreibbar.
Alles so schöne, wahrscheinlich müsste man auch nochmal sagen, sicher, benutzbar.
Also eigentlich die ganzen Produktqualitäten, die man so braucht.
Also ich vermute der, it runs on my machine.
Effekt wird wesentlich zunehmen in Zukunft.
Aber das ist halt nichts, was ich verkaufen kann.
Nur weil das bei mir läuft, heißt das nicht, dass das in irgendeiner Form als Produkt verwertbar ist.
Und ja, das sind halt genau die zweiten 99 Prozent, die den Versuch vom Produkt unterscheiden.
Und ich meine, was halt...
Was, glaube ich, bei der Produktwertung von ganz, ganz vielen unterschätzt wird, also ich kenne ja auch so ein bisschen die Startup-Szene, das sind halt die Prozesse, die du neben dem Programmieren auch etablieren musst.
Da geht es um, wie kann ich Support abwickeln?
Wie kann ich rausfinden, unter welchen Edge-Cases Leute das benutzen?
Wie kann ich rausfinden, was jemand getan hat?
bei dem das nicht funktioniert und dann passieren seltsame Dinge oder sowas.
Und all diese Sachen, dafür brauche ich als Organisation, die ein Produkt auf den Markt bringt, irgendwelche Prozesse, mit denen ich das hinbekommen kann.
Und da hilft mir überhaupt nicht, wenn ich das irgendwie, ja, wenn ich bei der Entwicklung, beim Programmieren automatisieren kann und der ganze Spaß.
von Tools, ob jetzt AI oder sonst was ausgespuckt wird, sondern da geht es wirklich darum, ich brauche Organisationsprozesse.
Und die werden erst mal dadurch nicht, die entstehen dadurch nicht und die könnten vielleicht an der einen oder anderen Stelle davon profitieren, aber jetzt nicht substanziell, weil das ganz, ganz vieles ist, was außerhalb meiner Organisation stattfinden wird, wo diese ganzen Effekte dann auftreten.
bei denen Dokumentation, Installierbarkeit, Erweiterbarkeit, Betreibbarkeit oder sowas relevant wären.
Ja gut, ich könnte mir trotzdem vorstellen, wenn sowas, du hast schon alles in place und du willst halt einfach ein neues Feature rausbringen, wobei, wenn ich jetzt so drüber nachdenke, auch so ein Kunde von uns, ja, also vielleicht so ein Teil von Code-Generierung kann man da schon.
Kann man schon vielleicht deutlich schneller sein, aber insgesamt am Gesamtprodukt ändert sich tatsächlich dann gar nicht so viel, aber vielleicht an den reinen Entwicklungskosten schon.
Also Marketing und Sales und Prozesse drumherum, also das wird man so oder so immer brauchen.
Ja, also was da glaube ich passieren wird, und das ist was, da muss man auch nochmal auf diese Teergrube anders drauf gucken.
Letzten Endes, also wenn, ich formuliere jetzt mal die Hypothese, dass es uns gelingt mit geeigneten Werkzeugen und dem Einsatz von AI, meinetwegen irgendwelchen Agents, zuverlässig Code zu erzeugen, der läuft und tatsächlich das Problem löst und wo ein Test sagt, können wir gelten lassen.
Nehmen wir das mal als Gesetz an, dann tritt ein Effekt ein, der in etwa so ist wie die Einführung von Bugern auf Baustellen.
Wir hatten früher 50 Leute, die eine Grube für so ein Haus ausgehoben haben.
Die sind dann mit Schaufeln und Schubkamen gekommen und haben da ihren Lohn dafür bekommen, dass sie das gemacht haben, sind bezahlt worden und haben die Grube ausgehoben.
Dann kam irgendjemand auf die schlaue Idee, so einen Bagger zu bauen.
Und der Bagger, da habe ich jetzt bloß noch einen gebraucht, der hat in der gleichen Zeit mit dem Bagger das gemacht, was vorher 50 Leute mit Schubkarn und Schaufeln in der Zeit ausgehoben haben.
Und jetzt kommst du plötzlich in einen Punkt, wo du über Softwareentwicklung und auch den Wert von Softwareentwicklung anders nachdenken musst, weil du kannst jetzt natürlich nicht sagen als Unternehmen, der Baggerfahrer oder die Fahrerin kostet das Gleiche wie jemand, der mit Schubkarn und Schaufel.
eine Baugrube ausgehoben hat.
Das heißt, man hat in der Baubranche irgendwann angefangen, die Masse an versetzter Erde abzurechnen.
Du zahlst keine Miete für den Bagger, sondern du zahlst pro Kubikmeter Erde, die du bewegst, bezahlst du halt Geld.
Und das, was der Baggerfahrer da anlohnt, das ist irgendwie unter ferner Liefen.
Das ist gar nicht mehr so.
Und jetzt rutschen wir plötzlich, wenn diese Hypothese zutrifft mit denen.
mit den Coding Agents, wirtschen wir plötzlich in eine ähnliche Situation, dass ich mir über den Wert von Software plötzlich anhand von solchen Faktoren Gedanken machen muss.
Und wie klug oder wie wenig klug das ist, hatten wir ja schon mal gehabt in der Branche.
Also sind beispielsweise die auf LinkedIn heute gerne zitierten Lines of Code eine gute Metrik, anhand derer man abrechnen kann oder auch Erfolg messen kann?
Oder sind sie das nicht?
Wir werden sehen.
Ja, aber ich meine, ich könnte mir, sagen wir mal, die Lines of Code bei LinkedIn, was ich mir ganz gut vorstellen kann, ist vor, also irgendwann So agile Softwareentwicklung, ich denke jetzt einfach so bis 2010, 2011, da war die Methodik an sich, wie funktioniert Scrum, wie funktioniert X-Premium Programming und so weiter, das war an sich noch interessant.
Und dann ab 2012 oder 2013 ist ja so ein bisschen, ist in zwei Richtungen gekippt.
Also die breite Masse hat Agile by Name gemacht, aber sonst halt auch nichts.
Aber die anderen, die sozusagen in das in Anführungszeichen postagile Zeitalter sind, die haben ja gesagt, okay, wir messen Fortschritt anhand von Benutzer finden unsere Software gut.
Also wir messen, wie unsere Software benutzt wird.
Wir finden schnell raus, ist das überhaupt das, was Leute gut finden?
Hat jetzt irgendwie bis auf die...
Die guten Top-Player, würde ich mal sagen, ist halt nicht so richtig in die Breite gekommen, wirklich zu verstehen, wie wird mein Feature angenommen.
Aber das ist ja auch eher die Währung, in der man bezahlen sollte und jetzt nicht Lines of Code.
Also ich kann wahrscheinlich immer ziemlich viel generieren, aber so Sachen, die vor 12, 13 Jahren hip waren, also den User verstehen, die Nutzung unserer Software verstehen.
und entsprechend die Software verbessern, könnte deutlich wichtiger werden.
Aber sage ich so, war eigentlich schon immer wichtig, aber es hat trotzdem nur 10% interessiert.
Ich weiß nicht, ob das nur 10% interessiert hat oder ob tatsächlich das nicht von einer anderen Stelle aus gedacht werden müsste, nämlich von...
wie gut sind Organisationen dazu in der Lage, das zu adaptieren, dieses Bedürfnis.
Weil letzten Endes diese Relevanz von Nutzerverhalten, die ist auch schon in den 70ern diskutiert worden.
Also ich denke an Lehman's Laws und sowas.
Das kam genau aus der Denkweise raus.
Und die meisten Unternehmen, mit denen ich zu tun habe, beschäftigen sich schon seit vielen, vielen Jahren damit, wie muss eigentlich Software beschaffen sein, damit sie gut benutzt werden kann.
Kriegen das aber zum Teil nicht hin, weil es ist halt ein Unterschied, ob ich Google bin und eine Suchmaske programmiere mit genau einem einzigen Eingabefeld oder ob ich irgendeine Behörde bin, die mit Formularen zu tun hat, bei denen halt 140 Eingabefelder ausgefüllt werden müssen.
Ja, also ich habe jetzt gar nicht so sehr auf UX drauf geguckt, sondern auf Nützlichkeit.
Und sagen wir mal so, UK Digital Government ist ja bekannt dafür, dass die die große Maßgabe gemacht haben, keine Sau will auf unsere Webseite kommen.
Du kommst nur auf unsere Webseite, wenn du musst.
Und deswegen werden wir alles dafür tun, damit du so schnell wie möglich wieder von unserer Webseite verschwinden kannst und dein Job erledigt ist.
Aber da denken halt relativ wenige Entwicklungsteams drüber nach.
Wir sagen einfach, ja, wir haben User Research gemacht und wir haben die gefragt, was sie wollen und jetzt bauen wir das, ohne dann wirklich nachzuprüfen, wie wird es denn genutzt, hat es wirklich das Problem gelöst.
Aber das ist genau der Punkt, den ich meine, sind die in der Lage, das umzusetzen?
Weil es gibt ja schon aus dem, also das war so in den 90ern, wo so diese Hypothese diskutiert worden ist.
Menschen sind erst dann in der Lage, ihre Anforderungen an ein interaktives System zu formulieren, wenn sie mit dem System arbeiten.
Das heißt, ich kann gar niemanden vorher fragen, wie würdest du denn dieses System benutzen wollen, wenn es nicht da ist.
Ich kann nur Feedback nehmen und das dann integrieren und das System verändern an das Nutzerverhalten.
Und das ist was, das leisten sich die wenigsten Organisationen.
ist meine Hypothese ganz persönlich, also ohne dass ich es empirisch belasten kann, die haben das einfach nicht eingepreist.
Deswegen funktioniert das an vielen Stellen nicht.
Aber wie gesagt, ich denke, da liegt es eher an den Fähigkeiten, weniger an dem, dass sie sich nicht drum kümmern.
Da sehe ich aber ehrlich gesagt nicht, wie AI da helfen kann.
Weil wie sollte...
AI das beispielsweise antizipieren, wie Leute darauf reagieren werden, auf so ein interaktives System.
Ich glaube, das Versprechen ist eher, dass man noch schneller Experimente umsetzen kann.
Das heißt, man lernt schneller, aber das hat natürlich auch einen Haken.
Du kannst eigentlich ja auch nicht in so einem hohen Tempo ständig das System ändern.
Und vor allem wird das, glaube ich, häufig auch dann als Ausrede genommen, um einfach mal irgendein Feature auszuprobieren.
Du musst ja schon trotzdem auch vorher User Research machen und nicht einfach mal eine Hypothese in den Raum stellen.
Ja, das ist ein valider Punkt.
Gut, ich ziehe mal weiter zu unserem nächsten Punkt und zwar das Buch der mythische Mannmonat.
Der Titel kommt ja tatsächlich vom Kapitel der mythische Mannmonat.
Was sagt Fred Brooks, der Einsatz zusätzlicher Arbeitskräfte bei bereits verzögerten Softwareprojekten verzögert sie nur noch mehr.
Komplexe Programmierprojekte können nicht vollkommen in getrennte Aufgaben aufgeteilt werden, die ohne Kommunikation zwischen den Bearbeitern und ohne ein komplexes Beziehungswerk zwischen Aufgaben und Bearbeitern zu erledigen sind.
Genau, was sagt ihr dazu?
Bleibt das so oder wird es anders?
Gerrit nickt, bleibt so.
Ja, also es gibt keinerlei Evidenz dafür, dass sich das irgendwie ändert.
Ich habe von niemandem eine plausible Erklärung gehört, wie man das angehen könnte, dass sich das ändert.
Also das ist eine Problematik, liegt in der Natur der Sache.
Und ja, also es gibt jede Menge Empirie dafür, dass das stimmt.
Brooks da gesagt hat.
Ich kenne keinen einzigen, dem es jemals gelungen ist, das zu widerlegen.
Ich hatte vielleicht noch daran gedacht, also jetzt nicht der menschliche Bearbeiter, sondern was Agents angeht.
Also ich habe ein Agent-Team, das zu koordinieren ist.
Da kommst du aber auch sehr problematisch raus.
Also klar, die Agents können super parallel arbeiten an Features, wenn die Aufgaben leicht parallelisierbar sind.
Aber oft sind sie es ja eben nicht.
Oder nur vermeintlich.
Und ich glaube, das ist dann sogar eher schlimmer.
Die Menschen sprechen miteinander und merken vielleicht, oh hier, bearbeiten wir irgendwie, arbeiten wir an ähnlichen Dingen gerade, wir kommen uns irgendwie vielleicht in die Quere, lass uns mal absprechen.
Wenn du aber irgendwie fünf Agenten gleichzeitig unterschiedliche Aufgaben gibst, Features zu implementieren, dann arbeiten die halt schön fleißig parell und am Ende hast du fünf riesige Merge-Requests und die sehen alle vielleicht auch für sich gut aus, aber dann kommen wir wahrscheinlich nämlich zu dem nächsten Punkt, konzeptionelle Integrität.
Wenn man das alles zusammen wieder mergt, dann hat man vielleicht manche Konzepte plötzlich fünffach im Code, leicht unterschiedlich.
weil die alle schön gleichzeitig und völlig in Isolation bearbeitet wurden, diese Aufgaben.
Ja, da bringst du mich auf was.
Spannend finde ich, ja, es gibt ja so Ansätze, jetzt auch schon ohne Agenten, zum Beispiel von dem Löwi, dieses Buch Writing Software, ich weiß nicht, ob ihr das kennt, der ist ja so der klassische Ingenieursansatz eher, dass man so eine kritische Fahrtanalyse macht und so weiter.
um genau zu planen, in welcher Reihenfolge und welche Aufgaben man parallel abarbeiten kann.
Aber dafür brauchst du eben auch erstmal die menschliche Expertise.
Irgendjemand muss das ja auch planen.
Und ja, das ist halt auch nicht trivial.
Ich glaube, da kann man auch mal daneben liegen, wenn man das jetzt vorher alles planen möchte, was parallel machbar ist.
Und spannend finde ich vor allem, es gibt ja eigentlich auch schon in der menschlichen...
Im Vergleich zur agentischen Praxis eigentlich eine Gegenbewegung, die sich bewusst gegen diese Paralysierung entscheidet.
Ensemble Programming.
Wo du halt sagst, wir bearbeiten gar nichts parallel und haben dafür aber ein sehr hohes geteiltes Situationsbewusstsein.
Und vielleicht sind wir am Ende damit sogar schneller.
Oder zumindest machen wir wahrscheinlich höher qualitativere Software.
Aber das löst das Problem halt auch nicht.
Du kannst im Ensemble wahrscheinlich auch nicht das Problem lösen, dass du zu einer Teilen nach hinterher hingst, wie es jetzt im mythischen Mannmonat eben beschrieben ist.
Du hast gerade was bei mir getriggert übrigens, was zum komplexen Beziehungswerk zwischen Aufgabe und Bearbeitern, dass wir uns natürlich abstimmen können, weil das hat Ken Beck neulich gesagt.
Er hat halt gesagt, ja.
Also Ken Beck experimentiert ja ziemlich viel dabei rum, also ziemlich viel mit AI-Assistence rum.
Ein Problem ist natürlich, wir kriegen eine Aufgabe und dann fangen wir an, diese Aufgabe zu bearbeiten.
Aber während wir diese Aufgabe bearbeiten, fällt uns eigentlich auf, dass diese Aufgabe vielleicht nicht die richtige Aufgabe ist.
Also wir können Feedback an den Aufgabensteller geben und sagen, wir haben jetzt auf unserer Entwicklungsreise haben wir was gelernt, was wir relativ frühzeitig zurückspielen können.
Und das wird jetzt, also das fällt jetzt, fällt es aus?
Oder merken wir es später?
Keine Ahnung.
Also laut Kent Beck fällt es aus, wenn ich mich richtig erinnere.
Also du hast dann ein Ergebnis und dann, also irgendwann fällt es auf, dass das Ergebnis vielleicht das richtige ist.
Aber die Die Auseinandersetzung mit der Aufgabe, die gibt es in dem Sinn nicht mehr.
Ich denke, es kommt darauf an, wie du die AI einsetzt.
Wenn du wirklich dem Agenten ein Feature gibst zum Entwickeln und dann gehst du halt was anderes machen, dann fällt das aus.
Dann ist er halt fertig.
Und du hast es vielleicht.
Aber wenn du diesen Omega-Programming-Ansatz verfolgst, dass du quasi Pair-Programming mit deinem Agent zusammen machst und der kleinere...
Code für dich generiert und du wirklich permanent dabei bist, drüber nachzudenken, was da gerade passiert und neue Teilschritte zu formulieren, dann merkst du es dir wahrscheinlich schon.
Alright.
Habt ihr noch was zum Thema mythischer Mannmonat?
Sonst würde ich vielleicht noch eins machen, sonst für eins haben wir noch Zeit.
Wie viele haben wir denn insgesamt noch?
Also wir hätten noch offen Konzepte.
Ja, wir hätten noch konzeptionelle Integrität, das Ärzteteam und Spezialwerkzeuge.
Zur Not kriegen wir vielleicht noch zwei hin.
Ja, ich finde ja, also entweder machen wir jetzt noch ein oder zwei oder wir machen noch eine zweite Folge.
Tempting.
Dann würde ich sagen, dann machen wir noch eine zweite Folge.
Ich glaube, das wäre dem Buch sonst nicht gerecht, oder?
Ja, da können wir nochmal das hier so ein bisschen sacken lassen und haben wir nochmal einen Cliffhanger für die Zuhörer.
Und ich hatte eh das Feedback bekommen, mehr kleinere Folgen.
Also von Hörern, idealerweise Scott Hanselman hat ja immer zwischen 30 und 40 Minuten, passt in einen Commute.
Da sage ich, naja, eine Stunde passt in Hin- und Rückfahrt, aber das hat Leute irgendwie nicht so überzeugt.
Okay, dann würde ich sagen, machen wir einfach konzeptionelle Integrität, Ärzteteam und Spezialwerkzeuge beim nächsten Mal.
Also ich glaube auch Spezialwerkzeuge werden wir wahrscheinlich ein paar Stück brauchen, ist so meine Meinung.
Und dann würde ich mich jetzt...
Auf jeden Fall bei allen bedanken, die bis hierhin durchgehalten haben und natürlich auch bei euch beiden.
Vielen, vielen Dank.
Danke für die Einladung.
Ja, gerne.
Ciao, ciao.