Ich habe in meiner Karriere in Hunderten von Vorträgen gesessen, und gefühlt die Hälfte davon haben sich rituell und performativ am Wasserfallmodell abgearbeitet.
Wir brauchen glaube ich mal einen Steelman-Vortrag zum Wasserfall. Ein Vortrag, der dem Publikum ernsthaft zu verkaufen versucht, wieso man das machen sollte.
Ich finde das ja generell sehr abstoßend, wenn Leute alle performativ gegen irgendwas sind, weil alle anderen auch dagegen sind. Am besten etwas, das jahrzehntelang Stand der Technik war, und von den erfolgreichsten Organisationen seiner Zeit verwendet wurde. Eine Methode, ohne die wir keine Mondlandung und keine Computer hätten.
Ich verstehe ja, dass die Entwickler das alle unsexy finden. Das Modell hätte auch versagt, wenn das nicht so wäre. Denn das Wasserfallmodell kommt halt aus dem Management und versucht, Entwickler möglichst austauschbar (und billig!) zu halten. Wasserfall versucht das Fordsche Fließband-Konzept auf Softwareentwicklung anzuwenden.
Die Entwickler sollen möglichst wenig Verantwortung übergeben kriegen, und bitte keine Entscheidungen treffen, die sich später rächen können. KLAR finde ich als Entwickler das scheiße! Ich möchte gerne eine Schneeflocke sein, einzigartig und wertgeschätzt für meine großartigen Fähigkeiten.
Wir sind ja inzwischen sogar noch viel weiter. Softwareentwickler nehmen die Situation regelmäßig so wahr, dass sie nach einem Software-Projekt mehr Domain Knowledge haben als der Kunde, für den sie die Software schreiben!
Softwareentwickler halten sich genau so gerne für Gott wie andere Diziplinen!
Für den Kunden (und für die Firma, die mich angestellt hat!) ist es aber besser, wenn der Entwickler ein Rädchen im Getriebe ist, dessen Fähigkeiten sich darauf beschränken, sich zu drehen. Und zwar so schnell und in die Richtung, die vom Domain Expert vorgegeben wird. Das war damals eine separate Berufsbezeichnung, nannte sich Softwarearchitekt. Heute ist Softwarearchitekt bloß ein Pay Grade in vielen Firmen, wo man halt nach soundsovielen Jahren hinbefördert wird als Entwickler.
Genau wie wir mit Devops die Ops-Leute abgeschafft haben, und mit DevSecOps die Security-Leute, und mit Agile die Tester, genau so gab es bei Wasserfall noch Architekten.
Genau wie es sich bei DevOps herausgestellt hat, dass du nicht einfach die Entwickler nebenher Ops machen lassen kannst, und das dann insgesamt billiger wird, genau wie sich bei DevSecOps herausgestellt hat, dass du nicht einfach Entwickler auch Security machen lassen kannst, und dann wird das billiger oder besser, genauso hat sich nach der Wasserfall-Abschaffung herausgestellt, dass nicht jeder "Entwickler" das Zeug zum Softwarearchitekten hat. Aber die Entwicklergehälter sind halt entsprechend hochgegangen, daher ist das heute normal, dann halt auch Architektur zu erwarten von denen.
Typische Ausreden gegen das Wasserfallmodell sind "Wir haben gar keine Domain Experts". Ich halte das für Bias von Entwicklern, die trotzdem das Projekt machen und Geld verdienen wollen. Klar sagen die dann nicht, was sie sagen sollten, nämlich: Dann können wir diese Software nicht seriös anbieten. Die sagen lieber "pass uff, Atze, wir machen das agile. Die Software ist fertig, wenn ihr kein Geld mehr nachschießen könnt. Wenn ihr immer schön mithelft, wird das vielleicht was. Vielleicht auch nicht."
Das sind Zustände wie beim Berliner Großflughafen [0]! Da schäme ich mich für meine Profession, wenn da solche Marktteilnehmer rumlaufen!
Inzwischen hat sich das aber nicht nur durchgesetzt, sondern es hat die Gesamtsituation, dass Software halt nie fertig ist, immer teurer wird, und das Problem nicht löst, so normalisiert, dass die Leute das für normal halten.
Die Leute haben nicht Wasserfall gemacht, weil sie böse Menschen waren, sondern weil das Modell Dinge versprochen (und zumindest teilweise eingelöst!) hat, die attraktiv waren.
Früher hatte man auch Fachkräftemangel. Die Antwort war: Dann nehmen wir die Leute, die wir kriegen können, für die Architektur und das Pflichtenheft und das Domain Knowledge, und das Eintippen des Codes können halbgeschulte bessere Tippkräfte machen.
Heute haben wir Fachkräftemangel, und die Antwort ist: Wir suchen alle nach "Full Stack Engineers" mit 20 Jahren Kubernetes-Erfahrung, die seit 50 Jahren Java programmieren, aber höchstens 25 Jahre alt sind.
[0] https://blog.fefe.de/?ts=a8c49f15
https://blog.fefe.de/?ts=98e04151