BDD, MDD, TDD und andere DDs haben mir und den Teams, mit denen ich gute Software bauen konnte, nicht besonders viel
gebracht oder wurden gar nicht erst eingesetzt. Domain Driven Design nehme ich hier raus, dazu gleich mehr.
Ein richtig gutes Framework oder eine richtig gute Methode zur Erhebung von Anforderungen habe ich in Projekten bisher
nicht mitbekommen. Da, wo dies gut funktioniert hat, hatten Leute ein glückliches Händchen dafür und die dafür notwendigen
Fähigkeiten zur Kommunikation. Ein einfaches Framework zur Orientierung wäre hier gut – ohne ‘-DD’ wäre klasse.
Einige werden hier Agile/Scrum nennen, aber Scrum und das, was heute als agil bezeichnet wird, ist
kompletter Bullshit – und leider der Standard. Entwickler werden zu Code Monkeys für die Implementation am Fliessband
degradiert. 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. Was dabei rauskommt, ist Bananaware – Produkt reift beim Kunden.
Das machen wir etliche Jahre 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 SPDD
(für 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, auf Deutsch: vernunft-getriebene Entwicklung. Die bleibt da auf der
Strecke, wo der Focus dauerhaft auf den neusten
Hypes und den neusten Tools und Methoden liegt, und dabei Das zu kurz kommt, worum es geht: funktionierende und gut wartbare
Systeme, die mit minimalem Aufwand an Zeit und Ressourcen das abbildet, wofür sie angedacht wurde (1). Das ist jetzt nicht so
Buzzword-verdächtig, aber wenn sich das trotzdem flächendeckend durchsetzt, können wir den Begriff und das bescheuerte
Akronym dafür wieder vergessen.
DDD (Domain Driven Design) kommt dem schon gefährlich nahe. Das, worauf es ankommt, sind die Benutzer und deren Probleme.
Eventuell bezahlen die als Kunden und wollen dafür was Funktionierendes sehen. Eventuell beruht kritische Infrastruktur
wie Ver- und Entsorgung auf dem System. Darauf sollte der Focus liegen und nicht auf irgendwelchen Tools.
Stattdessen bekommen wir mal wieder was vor die Füße geworfen, das die absolute Revolution verspricht. Das Ganze ist noch
nicht mal halb ausgegoren und seit gut zwei bis drei Jahren wird uns erzählt, wie wir damit umgehen sollen,
dass dabei was Vernünftiges rauskommt. Das mit den ‘Prompt Engineers’ mit wahnsinnigen Gehältern in den Hunderttausenden
war schon mal nichts. Die Party war vorbei, bevor sie überhaupt angefangen hat.
Verkauft sich trotzdem wie geschnitten Brot. Die Gier nach der angeblichen wahnsinnigen Leistungssteigerung und den
damit in Aussicht gestellten Gewinnen hat bei Scrum schon gut funktioniert (“doing twice the work in half the time”).
Leider nicht für das Software-Engineering, sondern für diejenigen, die
den Begriff ‘agile Softwareentwicklung’ gekapert haben und Zertifikatsmühlen zum Gelddrucken aufgestellt haben. Bei einem
Goldrausch verdienen die, die Schaufeln verkaufen. Von denen, die dann damit graben, schauen die meisten in die Röhre.
Mir fallen da ein paar Dinge ein, die in der Softwareentwicklung mehr zum Positiven verändern können, als genAI mit SPDD
und ähnliche tools & methodology madness. Einiges davon taucht hin und wieder mal in Tech-Szene kurz auf, bekommt aber leider
nie die Aufmerksamkeit wie die ganzen Hypes, die uns nicht weiter gebracht haben:
- Wir lassen den pseudo-agilen Scheiss bleiben und schicken alle ‘agile Coaches’ in die Wüste. Dave Thomas erklärt in
Agile is dead , warum. Er hat die agile
Bewegung mit ins Leben gerufen
und weiß besser, wovon er spricht, als Consultants und Coaches, die Dir nach einem zwei-Tage Kurs “Scrum-Master” erzählen wollen, wie
Dein Team am besten entwickelt. Meine zwei cents obendrauf: Beware of coaches that are not in the trenches with you.
- Denjenigen, die immer noch 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.
- Denjenigen, die uns die Nutzung von LLM Tools für Produktivsysteme nahe legen oder von uns fordern, machen wir den Unterschied
zwischen rationalem Denken und dem heuristischen Suchen einer Lösung klar (Heuristik: Ich lauf’ im Lösungsraum in die Richtung,
wo ich denke, dass ich am wahrscheinlichsten was finde und schaue, was mir dabei vor die Füsse fällt).
- Wir begreifen: Das Schreiben von Code ist nicht der Engpass in der Software Entwicklung.
- Wir lassen uns nicht auf firmen-gesponsorten Konferenzen einseifen, wo uns erklärt wird, warum es so dreckscool ist, mit
Framework X einen hello-world Microservice mit 300 MB zu deployen, oder wie wir mit ‘agentic coding’ die Schwächen von
genAI anscheinend ausmerzen können,
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.
- Wir hören auf, FDD (Fashion-Driven-Design) zu betreiben. Es ist völlig wurscht, ob jetzt gerade Vue oder Svelte oder React angesagt ist.
Wichtiger ist, ob es in etlichen Jahren noch relevant ist. Wenn Du Glück –oder Pech– hast, läuft das System, dass Du mit erstellst, ein paar
Jahrzehnte. Faustregel zum Abschätzen: wenn es richtig gut funktioniert und absolut langweilig ist, hat es Potenzial. Wenn Du was Cooles
brauchst, kauf Dir ein paar Sneakers oder ein paar nette Accessoires.
- Wir fangen an, einfache Lösungen zu schätzen, anstatt mit der barocken Komplexität von Systemen zu protzen.
- Wir lassen das Echo-Chamber Gelaber bleiben und hören auf, mantra-artig Dinge zu wiederholen, die nicht mehr stimmen oder noch
nie gestimmt haben, nur weil fast alle das so sagen. Anstatt auf Wellen mitzuschwimmen und Unfug wie ‘Monolith generell böhse’
und ‘Microservices generell viel besser’ unreflektiert weiter zu verbreiten, schauen wir uns an, wo Technologien herkommen, wie
sie sich in ihrer Historie entwickelt haben, und schätzen daraufhin ab, ob ein Einsatz im jeweiligen Kontext Sinn macht.
- Wir begreifen, dass Eleganz kein Luxus, sondern die Voraussetzung für stabile und flexible Systeme ist.
- Wir betreiben möglichst realistische Aufwandsschätzungen und stehen für diese gegenüber unseren Stakeholdern (Benutzer, Kunden, CEOs) ein.
Das beinhaltet, oft zu verhandeln und auch 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 wollen, dass ihre Produkte das erfüllen,
was wir zugesichert bekommen. Ich warte jetzt schon Jahre auf die Revolution, die mir Leute wie Eric Schmidt und Sam Altman versprochen
haben. Die haben schon ein paar mal nicht geliefert. Wenn deren genAI Tools für die Software-Entwicklung so gut funktionieren würden
wie angepriesen, 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.
(1) In dem Sinne sind für mich die Datacenter und die ungeheure Menge an Ressourcen und Energie zum Einsatz für genAI nicht
gerechtfertigt, wenn das, was rauskommt, vielleicht für MVPs, aber nicht für Produktivsysteme taugt.