Der mythische Bot-Monat – Teil 1

Dieses Transkript wurde automatisiert erstellt und nicht manuell überprüft. Es kann daher Fehler enthalten. Maßgeblich ist immer das im Mitschnitt gesprochene Wort.

Sven Johann: Hallo und herzlich willkommen zu einer neuen Folge des INNOQ Podcasts. Heute mit Gerrit und Daniel zum Thema der mythische Mannmonat beziehungsweise der mythische Botmonat. Bevor ich loslege, vielleicht noch mal hallo Gerrit, hallo Daniel.

Daniel Westheide: Hallo. Wie geht’s euch?

Gerrit Beine: Hallo. Gut.

Sven Johann: Ja, wunderbar. Was macht ihr? Ich weiß, man muss euch wahrscheinlich nicht mehr vorstellen, aber vielleicht sagt noch mal einen Satz zu euch, jenseits des Senior Consultanttums.

Gerrit Beine: Ich fange an. 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. Ich bin mal ganz gespannt, wie es uns gelingt, die Thesen von Fred Brooks, die ja auch schon älter sind als ich, mit dem aktuellen Thema zusammenzubringen.

Sven Johann: Ja, Daniel.

Daniel Westheide: Ja, was ich ganz spannend finde, ich glaube, was Gerrit und mich verbindet, ist, dass wir beide eher so einen interdisziplinären Hintergrund haben und nicht reine Informatiker oder sowas sind. Als solcher habe ich halt auch vor einiger Zeit angefangen, mal zu schauen, was eigentlich zum Beispiel die Kognitionspsychologie uns darüber sagen kann, wie man mit AI Tools umgehen sollte oder auch nicht. Und Gerrit hat, glaube ich, noch mehr so die soziologische Perspektive dazu. Ergänzt sich, glaube ich, ganz gut.

Sven Johann: 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. Philipp Gade würde sagen, wir, nee, sollte man gar nicht sagen. Aber auf jeden Fall älter als wir ist dieses Buch der mythische Mannmonat, geschrieben 1975 oder 76 von Fred Brooks. Und der hat so ein paar Wahrheiten der Softwareentwicklung dort beschrieben, als er da an dem IBM, ich glaube an der Z Series oder sowas, 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, na ja, eigentlich hat sich daran nichts geändert. Und jetzt sind wir wieder, es sind wir sozusagen 30 Jahre weiter und jetzt sagen ja einige Leute, dass sich mit AI natürlich alles ändert und alles auf den Kopf gestellt wird. Und ja, wir wollen einfach noch mal durch ein paar Thesen durchgehen, wir werden nicht alles schaffen, aber wir diskutieren auf jeden Fall mal ein paar. Was so Klassiker sind, überhaupt der mythische Mannmonat, No Silver Bullet, 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 seit ein paar Wochen, oh, die SaaS Apokalypse kommt, die Aktien haben alle, wie wir Börsenexperten sagen, nachgegeben, was diese SaaS Firmen angeht. Ist alles vorbei, SaaS, ihr könnt alle einpacken, weil wir statt zu kaufen, wird gewonshottet sozusagen. Genau, sorry, jetzt habe ich schon ein bisschen vorweggenommen, ne? 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 Standard Software einzusetzen. Und ich denke, die Diskussion, die haben wir auch, ne? Make or Buy. Was ist so eure Meinung zur SaaS Apokalypse? Wird Coding dazu führen, dass wir keine Software mehr einkaufen?

Gerrit Beine: 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 Buy 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 Web-gecodeten eigenen Lösung. Ob das klug ist oder nicht, ist noch eine andere Geschichte, aber ich wage zu behaupten, dass das häufiger passieren wird.

Sven Johann: Ja, Daniel.

Daniel Westheide: Ja, also wenn man sich LinkedIn anguckt, dann macht das ja jetzt eigentlich fast jeder. Die SaaS Software nicht mehr einzusetzen, anstattdessen selbst zu schreiben, weil es irgendwie nur noch eine Woche dauert, woran diese Firmen irgendwie jahrelang gesessen haben, das umzusetzen und das klingt auch erstmal super, ne? 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 noch komplizierter ist. Und in diesen SaaS Anwendungen steckt halt so viel Erfahrung auch über die Domäne drin, ne? Mal ganz 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.

Sven Johann: 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, ja. Also da steckt schon ziemlich viel dahinter zu sagen, ich betreibe das nicht.

Gerrit Beine: 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 im Fokus, ich lagere das aus, bei dem ich sagen kann, wenn das ausfällt, weil der Betrieb der ausgelagerte 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 für 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 Webcode ich mir mal eben. So, da kommt dann auch eine Textverarbeitung raus, mit der ich arbeiten kann. Die Challenge ist aber bei der Software wie Word und da kann man auch noch andere Produkte dann hernehmen, liegt 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 der liegt der große Wert darin, dass das was gespeichert wird, austauschfähig ist mit anderen Leuten. Ich kann so eine Word Datei nehmen, kann die dir schicken, Sven oder dir Daniel und ihr seht die Word Datei genauso wie die bei mir angezeigt wird. Kann man jetzt bei Word immer drüber streiten, ob das so ist oder so, ne, 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 Webcode sich sein eigenes Word, werden wir genau an diesem Austausch scheitern. Und das ist das, warum das aus meiner Sicht eine irre Hürde gilt, sowas nicht off the Shelf zu kaufen und nicht von einzelnen Unternehmen entwickeln zu lassen, sondern zu sagen, ich Webcode mir das mal eben. Und ich möchte an der Stelle noch mal sagen, also ich benutze natürlich Libre Office, ne? Ich benutze nicht Word. Aber das Austauschformat ist häufig trotzdem genau das.

Sven Johann: Ja, ich würde auf jeden Fall noch 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 Logistiksparte ist total wichtig und dann haben die natürlich Routenplanungssoftware 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. Ja klar, das Weltwissen weiß ja, wie man Routenplanung macht. Und da denke ich, ja, also vielleicht, ne, aber nehmen wir an, das Weltwissen würde wirklich wissen, wie man Routenplanung macht. Es müsste das ja auch korrekt implementieren. Und irgendjemand müsste entscheiden, dass das korrekt ist, weil wenn ich einen Bug habe und es funktioniert nicht so, ne, was macht man dann, ne? Also, dann hat man echt geloost. Von daher sehe ich das halt, also ich sehe es definitiv nicht so, ja. Ja, eine Sache, die dieselbe Person gesagt hat, wo ich aber meine Meinung tatsächlich geändert habe, war Domänen Know-how und da wird mich auch eure Meinung mal dazu interessieren, wenn ich jetzt SAP nehme und SAP hat also irgendwie, also macht ERP Software, ja. Und ich könnte jetzt für, ich könnte jetzt 3 Millionen Zeilen konfigurieren, ja, 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.

Gerrit Beine: 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 sag, 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. Also da geht’s 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 noch 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 stark ins Customizing von SAP gehen.

Sven Johann: 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 Buy, kippen wir in Zukunft tendenziell mehr auf Make, aber vermutlich bleibt das so bis auf, ich sag mal so, dieses Randgebiet.

Gerrit Beine: Ich vermute, dass es eher so bei denen ist, die auf der Kippe standen, die früher eher tendenziell in Richtung Buy gekippt 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

Sven Johann: Habe ich nicht das, habe ich nicht.

Gerrit Beine: Glaube ich.

Sven Johann: Ich habe gedacht, ich hätte das gesagt.

Gerrit Beine: Ich habe es ein bisschen anders verstanden, aber dann haben wir es noch mal geklärt.

Sven Johann: Gut. So, jetzt würde ich mal auf die Klassiker kommen. Der berühmteste oder einer der berühmtesten Sätze aus dem Buch ist ja „No Silver Bullets“, keine Silberkugeln, also die Silberkugeln, die den Werwolf töten. Fred Brooks 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 10 Jahren wenigstens eine Größenordnung, das Zehnfache an Verbesserungen bei Produktivität, Zuverlässigkeit oder Einfachheit zu garantieren. Da würde ich sagen, die Versprechen sind alle, wir sind jetzt, wir sind alle 10X, oder?

Daniel Westheide: Ja, aber da sind ja drei entscheidende Wörter drin: „für sich allein“. Und Brooks hat ja nie behauptet, dass einzelne Verbesserungen nichts bringen. Es kann ja theoretisch sogar sein, dass KI irgendwie bei der Implementierung uns eine zehnfache Verbesserung oder Produktivitätssteigerung gibt. 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 Requirements Engineering, Domänenverständnis, User Research oder auch die ganzen organisatorischen Entscheidungsprozesse, die werden dann halt zum dominanten Flaschenhals. Deswegen finde ich, dass agentische Entwicklung eigentlich das beste empirische Argument für Brooks These ist, dass das also immer noch gilt. Außerdem haben wir jetzt immer nur über Produktivität gesprochen. Das hatte ich auch immer nur so im Kopf, wenn man über die Silver Bullet von Brooks spricht, aber du hast es ja gerade noch mal gesagt, es geht auch um Zuverlässigkeit und Einfachheit. Und zumindest bei Zuverlässigkeit sagt die Datenlage, zum Beispiel die Dora Studie, die nimmt ab, seitdem die Leute sehr viel KI einsetzen für Code-Generierung. Und ich glaube auch, dass die KI nicht unbedingt den einfachsten Code generiert.

Gerrit Beine: Das würde ich auch unterschreiben. Gerade das Thema Einfachheit ist bei einem System, das intern nicht auf Determinismus basiert, etwas, das kriegen wir nicht gewährleistet. Ein stochastisches System ist notwendigerweise in der Wahrnehmung dessen, der es beobachtet, immer komplizierter, komplexer vielleicht, als ein System, das sich deterministisch verhält. Da glaube ich nicht, dass uns das in Richtung Einfachheit 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.

Was Daniel angefangen hat, das ist 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 etwas, was die letzten 40 Jahre kontinuierlich bestätigt wird. Es gibt immer dieses mit Augenzwinkern zitierte Solow-Paradox: „You can see computers everywhere but in the productivity statistics.“ Man kann natürlich sagen, 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? Wenn man als Kannibalist mal loslegt und das misst, stellt man fest, na ja, wir können jetzt zwar mit diversen Methoden, Tools und Frameworks im Arbeitsprozess noch mal 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 % 10 % mehr machen. Das heißt, ich reduziere diese 3 % im Anteil auf 2,7 %. Aber die 97 %, 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 ein oder anderen Stelle durchaus sein kann, wird das nach außen überhaupt nicht sichtbar werden.

Sven Johann: Hm, also ich meine, du sprichst ja Value Stream Mapping an, also, dass man halt guckt, wo wir werden nicht schneller dadurch, dass wir schneller arbeiten, sondern wir werden schneller, indem wir weniger warten, ne? 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 alle Value Stream Mapping machen, um schneller zu werden.

Gerrit Beine: Ich glaube, das hat uns weitergebracht, aber es ist halt anstrengend es anzuwenden, deswegen macht es keiner, und die meisten Unternehmen sind gut genug, deswegen haben die keine Notwendigkeit, es zu machen.

Wenn ich mich auf einem Markt behaupten kann als Unternehmen, muss ich nicht besser werden. Wozu?

Sven Johann: Ich komme noch mal kurz auf Zuverlässigkeit und Einfachheit zurück. Letzte Woche hatte ich eine lustige Diskussion beim Kunden. Wir haben natürlich über Software Engineering ziemlich intensiv diskutiert. Da sind wir auch auf das Thema Zuverlässigkeit gekommen. Es gab Microsoft Windows Nutzer, die sich massiv beschwert haben, dass das neue Windows, ich weiß nicht, was es ist, 11, 12, 13, auf jeden Fall das neue Windows, was mit großer Hilfe von Copilot entwickelt wurde, im Grunde genommen unbenutzbar ist. So haben die es gesagt, ja, kannst du eigentlich nicht nutzen. Das beste Beispiel dafür, dass man echt, dass man was tun muss, ja? Und ich frage mich halt, wird man was tun oder nicht, ne? Das habt ihr ja auch so angesprochen. Werden wir uns einfach daran gewöhnen, dass Software in Zukunft total grottig ist? Genauso wie das neue Windows.

Daniel Westheide: Ich weiß nicht, grottiger geht immer, oder?

Sven Johann: Ja.

Daniel Westheide: Es gibt ja auch Stimmen, die sagen, in den letzten 10 Jahren ist die Software schon viel grottiger, als sie in den 90ern zum Beispiel war. Aber ich hoffe, dass wir uns nicht daran gewöhnen, sondern dass es irgendwann so schlimm ist, dass man dann eine Kehrtwende macht.

Gerrit Beine: Ich glaube, in anderen Bereichen haben wir uns da ja schon dran gewöhnt. Wenn man sich so anguckt, ich zitiere jetzt mal jemanden, ohne Namen zu nennen, was so die Filmindustrie und die Musikbranche an Mainstream veröffentlicht, hat die Varianz abgenommen und die Durchschnittlichkeit ist jetzt nicht unbedingt nach oben gedriftet, sondern tendenziell eher so einem Mittelfeld geblieben, ja? Jetzt mal einzelne Künstler und Künstlerinnen ausgenommen, aber so im Mainstream ist da so eine gewisse Gleichförmigkeit, an die gewöhnt man sich natürlich. Ich meine, ich kann mich auch an die 90er an Windows 3.1 erinnern, das 17 Mal am Tag abgestürzt ist, wo man dann so einen Hard Reset gebraucht hat. Das waren auch keine tollen Zeiten, ne? Ob da jetzt wirklich so viel schlechter geworden ist, kann man diskutieren, aber ich kann mir vorstellen, dass da schon eine Gewöhnung einsetzt in Bezug auf Mittelmäßigkeit. Nicht unbedingt, 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.

Sven Johann: Ja, wir werden sehen. Ich hatte neulich noch gelesen, dass Claude Code netto 110 neue Bugs jeden Tag produziert. Die produzieren 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 6500, also das ist natürlich jetzt auch wieder ein paar Tage her, ne? Na ja, und da kommen auch Stimmen, dass das halt, dass einfach zu viele Glitches 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 auch gedacht, okay. Das hört sich nicht so gut an, was Zuverlässigkeit angeht. Mhm.

Gerrit Beine: 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, ich sag mal, Informatik als Ausbildungszweig gibt, geschult. Und mit genau dieser Idee, dieser Zuverlässigkeit, dieses Determinismus gehen die Leute jetzt halt auch an diese Codegeneratoren 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 Aufgaben Zuweisung 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 Erwartung 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 und 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 Kern, die Kernfähigkeit von allen Leuten, die Management machen.

Sven Johann: Okay, ja, wir werden sehen. Ich meine, bei Steve Yegge, der Guesstown entwickelt hat, sagt er ja selbst, du bist der Bürgermeister von Guesstown. Als Bürgermeister ist man vielleicht nicht unbedingt Manager, aber man muss trotzdem die Fäden in der Hand halten, ja? Okay, ich würde zum nächsten Punkt schwenken, und zwar zu einem meiner Lieblingspunkte in Zeiten von KI: die Teergrube. Was sagt Fred Brooks? Ich paraphrasiere: „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, ne? „Ich habe da mal irgendwas gewanshot, hat 37 Sekunden gedauert, und es kann ja jetzt wirklich nicht mehr so weit sein, da ein ordentliches Produkt rauszumachen.“ Ich könnte regelmäßig darüber ausflippen, aber was sagt ihr denn dazu? Daniel, willst du mal loslegen?

Daniel Westheide: Ja, du hast ja schon gesagt, dass man das jetzt ziemlich häufig sieht, ne? Auch gerade wieder auf LinkedIn prominent, Leute, die halt übers Wochenende irgendwie eine App entwickelt haben. Und ich glaube, deshalb ist auch diese Teergrube 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 Webcoding eben neue Software erstellen kann, ne? 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 keinerlei Erfahrung in professioneller Softwareentwicklung, haben aber übers Wochenende eben so eine App gebaut. Das heißt, die waren noch nie selbst in dieser Teergrube, in der der Softwareentwicklung in größeren Organisationen. Und haben das nie kennengelernt, glauben jetzt aber zu wissen, wie Softwareentwicklung funktioniert. So, 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 jetzt weniger werden, als es bisher vielleicht schon der Fall war.

Sven Johann: Das Verständnis wird weniger werden.

Daniel Westheide: Ja, genau.

Sven Johann: Das heißt, wir müssen mehr erklären, warum es länger dauert.

Daniel Westheide: 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.

Sven Johann: Ja, die ersten 99 % des Produkts dauern 99 % der Zeit und die restlichen 1 % dauert wieder 99 % der Zeit oder so. Ja. Aber du hast gerade erwähnt, was muss er denn noch alles tun? Was sind denn die ganzen Dinge, die in so einer Organisation noch anfallen? Was ist überhaupt so ein Programming Systems Product im Vergleich zum Garagenprogramm? Was würdest du dem Manager, dem Web-Coding-Manager erzählen?

Daniel Westheide: Ich glaube, das war eigentlich so eine Matrix, oder? Mit vier Elementen. Ja, so eine 2x2 Matrix, ja. Ein Programm, ein Programming Product und auch ein Systems Program oder sowas. Also bei dem Systems geht’s 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 hast du einfach nicht, ne? Integration zwischen verschiedenen Systemen, Kommunikation zwischen diversen Teams und so weiter. Und bei dem Product geht’s dann eben um Marktreife eigentlich, ne? Das ein stabiler Betrieb und so weiter. Und das sind alles Sachen, die erfährst du nicht, wenn du am Wochenende eine App baust.

Sven Johann: Irgendwie. Ja, ich habe mir noch dazu notiert, Marktreife ist irgendwie getestet, integriert, dokumentiert, installierbar, erweiterbar, betreibbar. Alles so schöne, wahrscheinlich müssen wir auch noch mal sagen, sicher, benutzbar. Also eigentlich die ganzen Produktqualitäten, die man so braucht.

Gerrit Beine: 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 %, die den Versuch vom Produkt unterscheiden. Und ich meine, was halt, was, was, glaube ich, bei der Produktwertung von ganz, ganz vielen unterschätzt wird, also ich kenne ja auch so ein bisschen die Start-up-Szene, das sind halt die Prozesse, die du neben dem Programmieren auch etablieren musst. Da geht’s 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 dem Markt bringt, irgendwelche Prozesse, mit denen ich das hinbekommen kann. Und da hilft mir überhaupt nicht, wenn ich das irgendwie, ja, wenn ich, wenn ich bei der Entwicklung, beim Programmieren automatisieren kann und der ganze Spaß von Tools, KI oder sonst was ausgespuckt wird, sondern da geht’s wirklich drum, ich brauche Organisationsprozesse. Und die werden erstmal 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.

Sven Johann: Ja gut, ich könnte mir trotzdem vorstellen, wenn du schon alles in place hast und einfach ein neues Feature rausbringen willst, wobei, wenn ich jetzt so drüber nachdenke, auch so ein Kunde von uns, ja, also vielleicht so ein Teil von Codegenerierung 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, ja. Also Marketing und Sales und Prozesse drum herum, also das wird man so oder so immer brauchen, ja.

Gerrit Beine: Also, was da, glaube ich, passieren wird, und das ist etwas, da muss man auch noch mal auf diese Teergrube anders drauf gucken. Letzten Endes, also, ich formuliere jetzt mal die Hypothese, dass wir tatsächlich, dass es uns gelingt, mit geeigneten Werkzeugen und dem Einsatz von KI, 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 gesetzt an, dann tritt ein Effekt ein, der in etwa so ist, wie die Einführung von Baggern auf Baustellen. Wir hatten früher 50 Leute, die eine Grube für so ein Haus ausgehoben haben, die sind dann mit Schaufeln und Schubkarren 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 Schubkarren und Schaufeln in der Zeit ausgehoben haben. Und jetzt kommst du plötzlich in den 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 Schubkarren 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 an Lohn, das ist das irgendwie unter ferner liefen, ne? Das ist gar nicht mehr so. So und jetzt rutschen wir plötzlich, wenn diese Hypothese zutrifft mit den Coding Agents, rutschen 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.

Sven Johann: Ja, aber ich meine, ich könnte mir, sag mal, die Lines of Code bei LinkedIn, was ich mir ganz gut vorstellen kann, ist, vor allem irgendwann so agile Softwareentwicklung, ich denke jetzt einfach so bis 2010, 2011, da war die Methodik an sich, wie funktioniert Scrum, wie funktioniert Extreme Programming und so weiter, das war an sich noch interessant. Und dann ab 2012 oder 13 ist ja so ein bisschen in zwei Richtungen gekippt, ne? Also die breite Masse hat Agile by Name gemacht, aber sonst halt auch nichts. Aber die anderen, die sozusagen in das in Anführungszeichen Post-Agile Zeitalter sind, die haben ja gesagt, okay, wir messen Fortschritt anhand von Benutzern, die unsere Software gut finden, ja? Also wir messen, wie unsere Software benutzt wird. Wir finden schnell raus, ist das überhaupt das, was Leute gut finden, ja? Hat jetzt irgendwie bis auf die guten Top Player, würde ich mal sagen, ist halt nicht so richtig in die Breite gekommen, ja? 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, ja. Aber ja, sage ich so, aber war eigentlich schon immer wichtig, aber es hat trotzdem nur 10 % interessiert, ja.

Gerrit Beine: Ich weiß nicht, ob das nur 10 % interessiert hat oder ob tatsächlich das nicht an einer von einer anderen Stelle ausgedacht 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 hat, die ist auch schon in den 70ern diskutiert worden. Also, ich denke da an Lehman’s Laws und sowas, ne? 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 das 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.

Sven Johann: Ja, also ich habe jetzt gar nicht so sehr auf UX geguckt, sondern auf Nützlichkeit. Und UK Digital Government ist ja bekannt dafür, dass sie 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?

Gerrit Beine: Aber das ist genau der Punkt, den ich meine mit: Sind die in der Lage, das umzusetzen? Weil es gab ja schon in den 90ern die Hypothese, dass Menschen erst dann in der Lage sind, 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 an das Nutzerverhalten anpassen. Und das ist etwas, das leisten sich die wenigsten Organisationen, und da ist meine Hypothese ganz persönlich, ohne dass ich es jetzt empirisch belegen kann: Die haben das einfach nicht eingepreist. Deswegen funktioniert es an vielen Stellen nicht. Aber wie gesagt, ich denke, da liegt es eher an den Fähigkeiten, weniger daran, dass sie sich nicht darum kümmern. Da sehe ich aber ehrlich gesagt nicht, wie AI da helfen kann, weil wie sollte AI das beispielsweise antizipieren, wie Leute auf so ein interaktives System reagieren werden?

Daniel Westheide: 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 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, aber du musst ja schon trotzdem auch vorher User Research machen und nicht einfach mal eine Hypothese in den Raum stellen.

Gerrit Beine: Ja, das ist ein valider Punkt.

Sven Johann: Ja, 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.

Gerrit Beine: Ja, also.

Sven Johann: Daniel nickt, bleibt so.

Gerrit Beine: Es gibt keinerlei Evidenz dafür, dass sich das irgendwie ändert, und ich habe von noch niemandem eine plausible Erklärung gehört, wie man das angehen könnte, dass sich das ändert. Also das ist eine Problematik, die in der Natur der Sache liegt. Und ja, es gibt jede Menge Empirie dafür, dass das stimmt, was Brooks da gesagt hat. Ich kenne keinen einzigen, dem es jemals gelungen ist, das zu widerlegen.

Sven Johann: Hm. Also ich hatte vielleicht noch daran gedacht, also jetzt nicht der menschliche Bearbeiter, sondern was Agents angeht. Also ich habe ein Agenten-Team, das zu koordinieren ist.

Daniel Westheide: Da kommst du aber auch aus der Problematik nicht raus. Also klar, die Agents können super parallel an Features arbeiten, wenn die Aufgaben leicht parallelisierbar sind. Aber oft sind sie es ja eben nicht oder haben nur vermeintlich. Und ich glaube, das ist dann sogar eher schlimmer. Die Menschen sprechen miteinander und merken vielleicht, oh, hier arbeiten wir an ähnlichen Dingen gerade, wir kommen uns 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 parallel 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.

Sven Johann: Ja, da bringst du mich auf was.

Daniel Westheide: 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 Pfadanalyse macht und so weiter, um genau zu planen, in welcher Reihenfolge und welche Aufgaben man parallel bearbeiten 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 zu agentischen Praxis, eigentlich eine Gegenbewegung, die sich bewusst gegen diese Parallelisierung 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 qualitative Software.

Sven Johann: Ja.

Daniel Westheide: Aber das löst das Problem halt auch nicht. Du kannst im Ensemble wahrscheinlich auch nicht das Problem lösen, dass du, wenn du zeitlich hinterher hängst, wie es jetzt im mythischen Mannmonat eben beschrieben ist.

Sven Johann: Ja, 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. Der hat halt gesagt, ja, wenn, also Ken Beck experimentiert ja ziemlich viel mit AI Assistants herum, der meinte, 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 was gelernt, was wir relativ frühzeitig zurückspielen können. Und das wird jetzt, also das fällt jetzt aus oder merken wir es später? Keine Ahnung. Also laut Ken Beck fällt es aus, wenn ich mich richtig erinnere. Also du hast ein Ergebnis und dann, also irgendwann fällt es auf, dass das Ergebnis vielleicht nicht das richtige ist, aber die Auseinandersetzung mit der Aufgabe, die gibt es in dem Sinn nicht mehr.

Daniel Westheide: Ich denke, es kommt drauf an, wie du die AI halt 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 Agenten 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 wahrscheinlich schon.

Sven Johann: Alright. Habt ihr noch was zum Thema mythischer Mannmonat? Sonst würde ich vielleicht noch eins machen, für eins haben wir noch Zeit.

Daniel Westheide: Wie viele haben wir denn insgesamt noch?

Sven Johann: Also wir hätten noch konzeptionelle. Ja, wir hätten noch konzeptionelle Integrität, das Ärzteteam und Spezialwerkzeuge. Meinst du, zur Not kriegen wir vielleicht noch zwei hin?

Daniel Westheide: Ja, also entweder machen wir jetzt noch ein oder zwei oder wir machen noch eine zweite Folge.

Sven Johann: Haha. Tempting. Dann würde ich sagen, dann machen wir noch eine zweite Folge.

Daniel Westheide: Ich glaube, das wäre dem Buch sonst nicht gerecht, oder?

Sven Johann: Ja, da können wir noch mal das hier so ein bisschen sacken lassen und haben noch mal einen Cliffhanger für die Zuhörer. Und ich hatte eh das Feedback bekommen, mehr kleinere Folgen. Also von Hörern, die es idealerweise Scott Hanselman hat ja immer zwischen 30 und 40 Minuten, passt in einen Commute. Sage ich, na ja, 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 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.

Daniel Westheide: Danke für die Einladung.

Gerrit Beine: Ja, gerne.

Sven Johann: Ciao, ciao.

Daniel Westheide: Tschüss.

Gerrit Beine: Tschüss.

Diese Zusammenfassung wurde automatisiert erstellt und nicht manuell überprüft. Es kann daher Fehler enthalten. Maßgeblich ist immer das im Mitschnitt gesprochene Wort.

Sven Johann, Gerrit Beine und Daniel Westheide diskutieren die These, dass KI-gestützte Code-Generierung das Ende von Commercial Off-the-Shelf (COTS) Software, insbesondere Software-as-a-Service (SaaS), einläuten könnte. Fred Brooks empfahl bereits 1975, Software nach Möglichkeit nicht selbst zu entwickeln, sondern Standardsoftware einzusetzen. Heute, so die Beobachtung, neigen Unternehmen dazu, bei der Make-or-Buy-Entscheidung eher zum „Make” zu tendieren, da die naive Annahme besteht, dass eine selbst entwickelte, KI-generierte Lösung kostengünstiger sei als das Customizing einer SaaS-Lösung.

Daniel Westheide weist darauf hin, dass die anfängliche Begeisterung über schnell generierten Code oft die Herausforderungen von Betrieb, Wartung, neuen Features und unvorhergesehenen Edge Cases ignoriert. Gerrit Beine ergänzt, dass der wahre Wert von Standardsoftware wie Textverarbeitungsprogrammen nicht nur in der Grundfunktionalität liegt, sondern vor allem in der Interoperabilität und dem Austausch von Daten. Eine Vielzahl selbstentwickelter Lösungen würde hier zu Kompatibilitätsproblemen führen. Die Experten sind sich einig, dass die Entscheidung, den Betrieb auszulagern, nicht mit der Entscheidung zur Eigenentwicklung vermischt werden sollte, insbesondere wenn es um geschäftskritische Systeme geht.

No Silver Bullet: Produktivität, Zuverlässigkeit und Einfachheit

Die Diskussion dreht sich um Fred Brooks' berühmte These „No Silver Bullet”, die besagt, dass es keine einzelne Entwicklung gibt, die eine zehnfache Verbesserung bei Produktivität, Zuverlässigkeit oder Einfachheit garantieren kann. Sven Johann stellt die Frage, ob die aktuellen Versprechen der KI-Tools, die eine zehnfache Produktivitätssteigerung suggerieren, diese These widerlegen.

Daniel Westheide betont, dass Brooks' These sich auf „für sich allein” stehende Entwicklungen bezieht. Auch wenn KI die Implementierung beschleunigen mag, verschieben sich die Engpässe dann auf andere Bereiche wie Requirements Engineering, Domänenverständnis oder organisatorische Entscheidungsprozesse. Gerrit Beine fügt hinzu, dass KI-generierter Code nicht unbedingt einfacher oder zuverlässiger ist. Er verweist auf Studien, die eine Abnahme der Zuverlässigkeit seit dem verstärkten Einsatz von KI zur Code-Generierung zeigen. Die Experten sind sich einig, dass die Komplexität von Software durch stochastische Systeme eher zunimmt.

Gerrit Beine hebt hervor, dass Produktivitätsgewinne im Programmieren oft nicht nach außen sichtbar werden, da der Großteil der Zeit in Organisationen durch Wartezeiten auf Entscheidungen oder andere Prozesse gebunden ist. Selbst eine Steigerung der Programmierproduktivität um 10 % würde den Gesamtprozess kaum beeinflussen, wenn 97 % der Zeit gewartet wird.

Die Teergrube: Vom Prototyp zum Produkt

Die „Teergrube” beschreibt das Phänomen, dass ein schnell erstellter Prototyp (z.B. am Wochenende) den Eindruck erweckt, ein vollständiges Produkt sei leicht zu realisieren, während die tatsächliche Entwicklung eines marktreifen Produkts ungleich komplexer und zeitaufwendiger ist. Daniel Westheide stellt fest, dass dieses Phänomen durch KI-Tools noch verstärkt wird, da nun jeder selbst erleben kann, wie schnell Code generiert wird. Dies führt dazu, dass Manager und Entscheider, die keine Erfahrung in professioneller Softwareentwicklung haben, ein verzerrtes Bild von der Komplexität der Softwareentwicklung bekommen.

Die Experten erläutern, dass ein „Programming Systems Product” im Gegensatz zu einem einfachen „Programm” Aspekte wie Testbarkeit, Integration, Dokumentation, Installierbarkeit, Erweiterbarkeit, Betreibbarkeit und Sicherheit umfasst. Gerrit Beine betont, dass neben der reinen Code-Erstellung auch organisatorische Prozesse für Support, Fehleranalyse und das Management von Edge Cases etabliert werden müssen. Diese Prozesse werden durch KI-Tools nicht automatisch geschaffen und sind entscheidend für den Erfolg eines Produkts am Markt.

Die Diskussion berührt auch die Messung von Softwareentwicklung. Während „Lines of Code” als Metrik kritisch gesehen wird, wird die Bedeutung des Verständnisses von Nutzerverhalten und der Nützlichkeit der Software hervorgehoben. Die Fähigkeit, schnell Feedback zu integrieren und das System an das Nutzerverhalten anzupassen, ist entscheidend, wird aber von vielen Organisationen nicht ausreichend berücksichtigt.

Der Mythische Mannmonat: Kommunikation und Koordination

Das Kernkapitel von Brooks' Buch, „Der Mythische Mannmonat”, besagt, dass der Einsatz zusätzlicher Arbeitskräfte bei bereits verzögerten Softwareprojekten diese nur noch weiter verzögert. Dies liegt daran, dass komplexe Programmierprojekte nicht vollständig in getrennte Aufgaben aufgeteilt werden können, die ohne Kommunikation und ein komplexes Beziehungswerk zwischen Bearbeitern und Aufgaben erledigt werden können.

Gerrit Beine und Daniel Westheide sind sich einig, dass diese These auch im Zeitalter von KI und Agenten-Teams weiterhin gültig ist. Selbst wenn Agenten Aufgaben parallel bearbeiten können, entstehen Herausforderungen bei der Integration und der Sicherstellung der konzeptionellen Integrität. Daniel Westheide warnt vor „riesigen Merge Requests” und der Gefahr, dass Konzepte mehrfach und leicht unterschiedlich im Code implementiert werden, wenn Agenten isoliert arbeiten.

Die menschliche Fähigkeit zur Abstimmung und zum frühzeitigen Feedback, wie von Ken Beck beschrieben, geht bei einem rein agentischen Ansatz verloren. Während Menschen während der Bearbeitung einer Aufgabe lernen und die Aufgabenstellung hinterfragen können, liefern Agenten möglicherweise ein Ergebnis, das zwar technisch korrekt ist, aber nicht das eigentliche Problem löst. Sie diskutieren, ob ein „Pair Programming” mit Agenten, bei dem der Mensch permanent den Prozess überwacht und steuert, eine Lösung sein könnte, um diese Probleme zu mindern.