Allmächt, noch eine weiteres xDD. BDD, MDD, TDD, und sonstwas-DD, das ging mir schon immer auf’n Zeiger.
Damit kann man wunderbar verbergen, dass man (oder frau) beim Entwickeln den Kopf nicht an hat.
Brauchen wir nämlich nicht. Wir wissen ja was zu tun ist. Schnell ein paar Frameworks zusammengesteckt,
ein bissel Gaffer-Tape drum rum, und ach ja, nicht vergessen: ein paar Tests anflanschen, für die grünen
Punkte in der IDE. Produkt reift dann beim Kunden (Bananaware).
Das machen wir ein paar Jahrzehnte und auf genau der Grundlage trainieren wir dann sowas wie Eliza on Steroids.
Wird sicher gut klappen. Wenn nicht, denken wir uns halt schnell einen neuen Hype aus.
Aber vorher denken wir uns ein neues Akronym aus, sowas wie
Structured-Prompt-Driven Development .
Das ist es schliesslich, was uns von Michi an der Stanze unterscheidet.
Wenn die Baubranche ähnlichen Blödsinn anstellen würde, wäre die beste und auch sicherste Behausung immer noch eine Höhle.
Wie wär’s zur Abwechslung mit Reason-Driven Development, oder einfacher: Rational Development.
Oder, auf deutsch, vernunft-getriebene Entwicklung. Besonders letzteres ist jetzt nicht sooo Buzzword-verdächtig, aber egal,
wenn sich das flächendeckend durchsetzt, können wir den Begriff und sogar das bescheuerte Akronym dafür wieder vergessen.
DDD (Domain Driven Development) kommt dem schon gefährlich nahe. Echt jetzt, es geht um die Domäne der Benutzer?
Also um deren Probleme? Gut möglich, eventuell bezahlen die als Kunden sogar und wollen dafür was Funktionierendes
sehen. Das sollte so klar sein, das wir dafür keinen Begriff wie DDD brauchen. Schlechte Nachricht für all die
Tool-Fetischisten da draussen.
Ich hab’ ein paar Vorschläge, die mehr zum Positiven verändern können als SPDD und die ganze restliche tools & methodology madness:
- Wir lassen den ganzen pseudo-agilen Scheiss bleiben und schicken alle ‘agile coaches’ in die Wüste.
- Denjenigen, die denken, mit dem Taylorismus von ‘Agile’ lässt sich Software wie am Fliessband raushauen, machen wir klar,
dass man Denken nicht beliebig klein zerlegen kann, weil dann das mit dem Erfassen komplexer Zusammenhänge gegen die Wand läuft.
- Wir arbeiten in interdisziplinären Teams aus Entwicklern und Experten aus der Dömane, also Benutzern, Kunden oder Key-Accountern
(nein, keine product owner, die sind auch schon in der Wüste).
- Denjenigen, die uns die Nutzung von LLM Tools nahe legen oder von uns fordern, machen wir den Unterschied zwischen rationalem
Denken und dem heuristischen Suchen einer Lösung klar (Heuristik: Ich stolper’ im Lösungsraum in die Richtung, wo ich am wahrscheinlichsten
was finde und schaue, was mir dabei vor die Füsse fällt).
- Wir begreifen, dass das Schreiben von Code nicht der Engpass in der Software Entwicklung ist.
- Wir schreiben Code, den auch Domänenexperten verstehen, die nicht programmieren können – im Sinne von “was macht dieser Code”. Wer sich jetzt fragt,
was hat der Typ geraucht – in so einer langweiligen Sprache wie Java geht das, das geht sogar in C. Wenn Du Dir sicher bist, dass das in “Deiner”
Sprache nicht geht und Du nicht in Assembler programmierst, dann frag’ Dich mal, warum. Und nein, ich meine nicht BDD, wo festgelegt ist,
wie welche Methode wie zu benennen ist. Wo Methoden das eigene Denken ersetzen, kommt am Ende keine gute Software heraus.
- Wir benutzen keine Tools mit leaky abstraction und keine Tools, an denen während einem Projekt mehr herum gefrickelt werden muss, als sich mit dem eigentlichen Problem
zu befassen – hallo Git plumbing commands, hallo Jenkins. Und ein ganz großes Hallo an all die LLM-Tools.
- Wir lassen uns nicht auf firmen-gesponsorten Kongressen einseifen, wo uns erklärt wird,
warum es so dreckscool ist, mit Framework X einen hello-world Microservice mit 300 MB zu deployen,
sondern machen uns klar, was Begriffe wie ’technology evangelist’ im Grunde bedeuten, und hören damit auf, uns von technology cheerleadern
irgendwas aufschwatzen zu lassen, weil es gerade so in ist. Was wirklich funktioniert, muss man nicht wie sauer Bier anpreisen.
- Wir fangen an, einfache Lösungen su schätzen, anstatt mit der barocken Komplexität von Systemen zu protzen.
- Wir begreifen, dass Eleganz kein Luxus, sondern die Voraussetzung für stabile und flexible Systeme ist.
- Wir betreiben realistische Aufwandsschätzungen und stehen für diese gegenüber unseren Stakeholdern (Benutzer, Kunden, CEOs) ein.
Das beinhaltet, bisweilen nein zu sagen, anstatt sich phantastische Versprechungen aus dem Kreuz leiern zu lassen.
Das bedeutet auch, neue Entwicklungen realistisch einzuschätzen, und da, wo der Kaiser nackt ist, ihn auch als solches zu bezeichnen,
anstatt in einer Masse von Jasagern mitzulaufen.
- Wir als Stakeholder wiederum erwarten von Firmen, die uns Tools für die Entwicklung verkaufen, dass ihre Produkte das erfüllen, was wir zugesichert bekommen
– hey Eric Schmidt, Sam Altman und wie ihr alle heisst: ich warte jetzt schon Jahre auf die Revolution, ihr hat schon ein paar mal nicht geliefert.
Wenn der ganze LLM-crap so gut funktionieren würde,
hätten wir schon längst sämtlichen Code von Bugs und Sicherheitslücken befreit. Das Gegenteil ist der Fall. Dafür, dass die kognitive Last bei der Entwicklung
mit LLM-Tools steigt, haben wir jetzt noch mehr Bugs und Sicherheitslücken im Code. Wem nützt der Deal, nach dem wir noch nicht mal gefragt haben?
- Vor allem aber: wir lassen diesen unsäglichen Tool-Fetischismus und diese unsägliche methodology madness bleiben, und machen nicht
jeden bescheuerten Hype mit.