Warum ist Software(-Architektur) eigentlich immer so schlecht?

[@distrologic2925]

Schön, dass es solche guten Beiträge über Software in deutscher Sprache gibt

[@EberhardWolff]

@@distrologic2925 Danke für das positive Feedback! 🙂

[@Aalii6]

Sehr interessant, vielen Dank!

[@EberhardWolff]

Gerne - danke für das positive Feedback!

[@danielpilsbacher7314]

Ich denke sauberes Requirement Engineering (bevor dem Techstack) an den funktionalen Anforderungen sollte durchgeführt werden, um vorab einige Probleme raus zu filtern. Bsp. man implementiert auf Basis von Annahmen, man erzeugt Kohärenzen und dann erst wird klar was nun die Anforderungen sind, dann wird es schwierig mit Änderungen.

[@EberhardWolff]

Sicher ist es sinnvoll, ein Projekt mit möglichst klaren Anforderungen zu starten. Aber das ist zum einen manchmal nicht möglich und Anforderungen ändern sich prinzipiell, weil Benutzer:innen und andere Stakeholder bei der Einführung der Software oder dem Nachdenken über die Software auf neue Ideen kommen. Daher kann das IMHO nur ein Teil einer Lösung. In dem Stream erkläre ich vor allem, dass Zeitdruck meiner Meinung nach ein Problem ist und ich glaube auch, dass dieses Problem größer ist als das der schlechten Requirments. Ich würde sogar sagen, dass es einen zu großen Invest in Requirements vor Beginn des Projekts geben kann.

[@DinHamburg]

@@EberhardWolff aber ab wann ist es denn 'Zeitdruck'? Was passiert, wenn man den entwicklern sagt 'schreibt solange ihr wollt, es gibt keine deadline' - wird das dann die _perfekte_ Software?? Zunächst wird es wohl die teuerste Software... Für 'Zeitdruck' sehe ich zwei Dimensionen: die einfache ist eine feste Deadline - 'wenn das Ding nicht zur Messe gezeigt werden kann, hat es sich erledigt'. Eine andere Dimension wäre Zeit in Verbindung mit Ressourcen - wenn ich eine Gruppe (zB) externer Entwickler bis Jahresende buche, können die (wahrscheinlich) nicht ohne Weiteres verlängert werden, weil die danach schon woanders eingeplant sind. Und natürlich Zeit in Verbindung mit Kosten - ein Team mit X Leuten kostet Y EUR in 3 Monaten, etwa 2*Y EUR in 6 Monaten - irgendwo gibts ein _finites_ Budget. _Das_ ist die Begrenzung, nicht der Kalender. Und das mit den Requirements - man kommt ja nicht drum rum - oder? Zunächst mal kosten Requirements kein Geld - es ist die _Umsetzung_ , die Geld kostet. Die Anforderungen nicht zu kennen, ist 'Nicht-Wissen'. 'Nicht-Wissen' ist Risiko. Risiko ist Eintrittswahrscheinlichkeit * Schadenshöhe. Der ganze Sinn von Abfragen von Anforderungen, Planung, QA ist die Reduzierung dieses 'Nicht-Wissens'. Es ist richtig, dass man nicht vor der ersten Code-Zeile die Breite des hintersten Datenfeldes wissen muss - man muss aber schon in etwa Wissen, wie groß diese Wissenslücke ist (genauer: die Summe aller Wissenslücken). Am Besten, _bevor_ man einen Vertrag mit Preis und Liefertermin unterschreibt. (Dabei kann es durchaus auch eine Wissenslücke 'nach innen' geben - wie genau kenne ich die Fähigkeiten/Motivation meiner Mannschaft?)

[@EberhardWolff]

@Dinhamburg Zeitdruck ist dann ein Problem, wenn gute Praktiken darunter zusammenbrechen. Ich habe ja auch nicht gesagt, dass Zeitdruck immer ein Problem ist. Manchmal muss man was liefern. Es hat halt nur Konsequenzen. Ich sehe das mit den Anforderungen genauso. Aber manchmal hat man nicht den Luxus, sie ausreichend am Beginn zu klären und sie ändern sich halt. 🤷‍♂️

[@distrologic2925]

Das Kernproblem ist dass Zielsetzung und Zeitplanung des Managements keine Anforderungen an die Wartbarkeit des Produktes stellen. Eine Anforderung müsste neben "Funktionalität x und y" auch "Umsetzung durch z und w" enthalten. Sowas beeinflusst die Zeitplanung und auch die Wartbarkeit des Produktes extrem aber es wird leider meistens zu Gunsten minimalen Zeitaufwands um gegebene Funktionalitäten umzusetzen entschieden, ohne für die Qualität des produzieren Codes zu planen.

[@EberhardWolff]

@@distrologic2925 In Prinzip sehe ich das auch so, aber Management muss der Trade Off auch vernünftig kommuniziert werden. Sie beauftragen halt oft Menschen wie mich, um aufzuzeigen wie die Wartbarkeit verbessert werden kann. Es ist ihnen also nicht egal…

[@holger_p]

Wenn man Software über 5 Jahre entwickelt, ändert sich halt einfach so viel, dass es immer schlechter wirkt, als wenn ich mit all dem Wissen von heute, auf dem Reißbrett neu entwickeln würde, und binnen 4 Wochen implementieren könnte. Passiert auch bei realer Architektur. Beim BER haben viele Leute ständig nachträgliche Wünsche gehabt, natürlich endete das im Chaos und wurde teurer. Man kann dem Kunden ja schlecht sagen "wir lehnen deinen Zusatzwunsch jetzt ab, das gibt unsere Architektur nicht her". Also macht man Abstriche am ursprünglichen Architekturkonzept ... denn das sieht der Kunde ja eh nicht, er honoriert sowas wie einfache Wartbarkeit nicht.

[@EberhardWolff]

@@holger_p Ja, Architektur erodiert und das habe ich in der Episode nicht diskutiert. Aber „er honoriert sowas wie einfache Wartbarkeit nicht“ finde ich schlicht falsch. Ein signifikanter Teil meiner Beratung sind gerade Menschen, die einfacherer Wartbarkeit ihrer Software wollen….

[@holger_p]

@@EberhardWolff das hängt davon ab, ob Du Menschen als Kunden hast, die was von Software verstehen, oder nicht. Ein BWLer mit Excel-Kenntnissen kommt gar nicht auf die Idee. Der haut zwar mit begriffen wie dynamisch, flexibel und änderungsfreundlich um sich, könnte aber nicht beurteilen ob etwas flexibel ist, wenn er davor steht. Und irgendwann kommt der Punkt "darf nicht viel kosten" und dann wird es quick&dirty. Architektur ist eine Investition in die Zukunft, die Auszahlung kommt Jahre später. Manche zahlen lieber später, als heute. Man muss es nur vermitteln, welche Konsequenzen Entscheidungen haben, auch um sich selbst zu rechtfertigen. "Wartbarkeit" ist mehr ein Versprechen, weil es nicht messbar ist.

[@EberhardWolff]

@@holger_pMeiner Meinung nach müssen wir besser darin werden, da Problem mit der Wartbarkeit zu kommunizieren. Darum geht es auch in dem Video. Wir können nicht erwarten, dass wir ein Budget für bessere Wartbarkeit bekommen, wenn die Gründe unklar sind. Gleichzeitig gibt es BWLer, die mich wegen mangelnder Wartbarkeit beauftragen.

[@holger_p]

@@EberhardWolff Richtig. Aber genauso wie automatisierte Tests, erklärt man sowas beim ersten Angebot nicht. Es gehört einfach mit dazu, es ist selbstverständlich und man spricht nicht drüber. Es wird nur dann zum Thema, wenn man es nachträglich separat einführt, oder ein Architekturupgrade macht, DI einführt oder sowas. Wenn es irgend geht, verstecke ich die Kosten dafür in Angeboten für Feature Upgrades und setze es einfach um, ohne dass der Kunde etwas davon mitbekommt. Es ist einfach schwer zu erklären. In anderen Branchen gibt es für solche Dinge oft die Ausrede "das ist so gesetzlich vorgeschrieben". Da fragt der Kunde dann nicht weiter.