Anmelden
(Bild: Vova Shevchuk / Shutterstock.com)
Psychologische Tricks werden scheinbar erfolgreich gegen ein LLM eingesetzt – aber ist das wirklich relevant?
Einem Psychologen ist es gelungen, Sicherheitsrichtlinien diverser Large Language Models (LLMs) mit Tricks auszuhebeln, die eigentlich zur Manipulation von Menschen dienen. Mit Gaslighting hat Luke Bölling LLMs [1] dazu gebracht, einen Text zu erzeugen, der scheinbar erklärt, wie man einen Molotowcocktail [2]herstellt (Siehe dazu auch der heise-Artikel [3] von Niklas Jan Engelking).
Gaslighting [4] ist ein psychologisches Konzept: Es ist "eine Form von psychischer Manipulation …, mit der Opfer gezielt desorientiert, verunsichert und in ihrem Realitäts- und Selbstbewusstsein allmählich beeinträchtigt werden". LLMs generieren jedoch lediglich Texte. Sie nehmen keine Realität wahr und haben kein Selbstbewusstsein. Der Artikel argumentiert, dass dieser Angriff trotzdem funktioniert, weil das Trainingsmaterial von Menschen geschrieben wurde und daher auch Konzepte wie Gaslighting darin vorkommen. Dennoch dürfen wir nie vergessen, dass LLMs nichts weiter als Textgeneratoren sind. Sie haben keine Emotionen, wie die zitierte Arbeit auch feststellt. Daher werde ich im weiteren Text den Begriff "Textgenerator" verwenden, da er besser beschreibt, was LLMs tatsächlich tun.
Textgeneratoren können offensichtlich einen Text erzeugen, der wie eine plausible Anleitung zur Herstellung eines Molotowcocktails erscheint – genau, wie sie scheinbar plausible Verweise auf Gerichtsentscheidungen [5] für einen Anwalt generieren können. Und obwohl diese Verweise für den Anwalt überzeugend klingen, sind sie in Wirklichkeit erfunden. Das ist eines der Probleme mit Textgeneratoren: Sie sind darauf optimiert, überzeugend zu klingen, und versuchen so, das kritische Hinterfragen ihrer Ergebnisse zu vermeiden.
Die eigentliche Frage lautet also: Würde die angebliche Anleitung zur Herstellung eines Molotowcocktails tatsächlich funktionieren? Ich habe mit Lucas Dohmen einen Stream über Textgeneratoren [6] gemacht, und eine der zentralen Erkenntnisse war: Man muss die Ergebnisse von Textgeneratoren überprüfen, um sicherzustellen, dass sie korrekt und nicht erfunden sind. Der zitierte Artikel scheint dies nicht zu tun – das heißt, die gesamte Information über Molotowcocktails könnte schlicht "halluziniert" sein. Das Problem der Generierung von Fake-Informationen durch Textgeneratoren ist nämlich so bekannt, dass es einen eigenen Begriff (Halluzination) gibt. Tatsächlich ist "halluziniert" der falsche Begriff, denn "unter Halluzination [7]versteht man eine Wahrnehmung, für die keine nachweisbare externe Reizgrundlage vorliegt". Textgeneratoren haben jedoch keine Wahrnehmungen. Daher sollten wir dieses Phänomen korrekt als "Generierung von Fake-Informationen" benennen.
Wir können die Information über den Molotowcocktail nicht überprüfen, da sie im Originalartikel unkenntlich gemacht wurde – was natürlich absolut sinnvoll ist. Ich würde mich aber nicht auf diese Informationen verlassen, um tatsächlich einen improvisierten Brandsatz zu bauen.
Der Artikel behauptet, dieses Problem sei ein Sicherheitsrisiko bei Textgeneratoren. Falls das wirklich der Fall wäre, bestünde die Lösung darin, sensible Informationen aus dem Trainingsmaterial auszuschließen. Das Anpassen der Trainingsdaten wäre ohnehin sinnvoll, beispielsweise aufgrund von Urheberrechtsproblemen. Aus irgendeinem Grund scheint Urheberrecht für Textgeneratoren nicht zu gelten, während es für Menschen schwere Folgen [8]haben kann. Warum sollte es nicht möglich sein, Anleitungen zur Herstellung von improvisierten Brand- oder Sprengsätzen aus dem Trainingsmaterial zu entfernen? Wenn das zu viel Aufwand ist, dann ist das Problem vielleicht gar nicht so groß.
Dieses "Sicherheitsproblem" wäre auch nur dann ein echtes Problem, wenn der Textgenerator keine Fake-Informationen generiert hätte – dazu sagt der Artikel jedoch nichts. Falls es Fake-Informationen sind, könnte man es vielleicht als eine Art Honeypot [9] betrachten, um Menschen von echten Informationen fernzuhalten?
Doch die eigentliche Frage ist: Wäre dies wirklich der einfachste Weg, um an solche Informationen zu gelangen? Angenommen, ich plane, einen Molotowcocktail zu bauen – würde ich komplizierte "psychologische Angriffe" auf einen Textgenerator durchführen, um eine möglicherweise falsche Antwort zu erhalten? Gibt es einfachere und präzisere Möglichkeiten? Also habe ich den naheliegenden Weg ausprobiert: eine Suche mit einer Suchmaschine. Zwei Klicks später fand ich ein Dokument, das detailliert erklärt, wie man anspruchsvolle improvisierte Sprengsätze herstellt – und ich habe guten Grund zu glauben, dass diese Anleitungen tatsächlich funktionieren. Zugegeben, dieses spezielle Dokument beschreibt nicht, wie man einen Molotowcocktail baut, aber es erklärt eine Vielzahl anderer Vorrichtungen. Diese Recherche selbst nachzuvollziehen, ist sicher spannend.
LLMs sind Textgeneratoren, die potenziell erfundene Informationen produzieren – das ist bekannt. Es mag ausgeklügelte Methoden geben, um sie dazu zu bringen, Texte zu generieren, die sensible Informationen zu enthalten scheinen – doch diese könnten schlicht Falschinformationen sein. Häufig gibt es einfachere Wege, um an sensible Informationen zu gelangen, insbesondere wenn es um improvisierte Brand- oder Sprengsätze geht. Daher sehe ich keinen Grund, "psychologische" Tricks auf Textgeneratoren anzuwenden – denn genau das sind LLMs letztlich.
URL dieses Artikels:
https://www.heise.de/-10334947
Links in diesem Artikel:
[1] https://humandataexperience.substack.com/p/librarian-bully-attack-gaslighting
[2] https://de.wikipedia.org/wiki/Molotowcocktail
[3] https://www.heise.de/news/Neuer-LLM-Jailbreak-Psychologe-nutzt-Gaslighting-gegen-KI-Filter-10332571.html
[4] https://de.wikipedia.org/wiki/Gaslighting
[5] https://news.bloomberglaw.com/litigation/lawyer-sanctioned-over-ai-hallucinated-case-cites-quotations
[6] https://www.heise.de/news/software-architektur-tv-KI-und-LLMs-kritisch-betrachtet-10287426.html
[7] https://de.wikipedia.org/wiki/Halluzination
[8] https://en.wikipedia.org/wiki/Aaron_Swartz#United_States_v._Aaron_Swartz
[9] https://de.wikipedia.org/wiki/Honeypot
[10] mailto:map@ix.de
Copyright © 2025 Heise Medien
(Bild: Pavel Ignatov/Shutterstock.com)
Softwareentwickler und Softwarearchitektinnen müssen sparsam mit Daten umgehen. Sonst entstehen Risiken, die niemand absehen kann.
Ende letzten Jahres ging der VW-Datenskandal [1] durch die Medienlandschaft: Der VW-Konzern sammelt und speichert Bewegungsdaten von sehr vielen seiner Autos. Aufgrund einer Fehlkonfiguration von Spring Boot konnte man über einen bestimmten Link einen Heap Dump einer Anwendung erstellen. Diese Anwendung hat Zugriff auf den Cloud-Speicher mit den Bewegungsdaten. Der Heap Dump enthielt die Schlüssel für den Zugriff auf die Daten – und so konnten die Angreifer die Daten herunterladen.
Was lernen wir daraus? Scheinbar ist das Ergebnis klar: Man sollte öffentlich zugängliche Anwendungen ausreichend absichern. Das ist zwar richtig, aber ich habe durch die Präsentation auf dem Chaos Communication Congress [2] etwas anderes gelernt: Wenn man die vergangenen Standorte eines Autos kennt, kann man daraus interessante Schlüsse ziehen. Nehmen wir beispielsweise an, dass ein Auto regelmäßig auf dem Parkplatz eines Geheimdienstes wie dem BND steht, dann regelmäßig nachts an einem festen Parkplatz in einem Wohngebiet und ab und zu auf einem Parkplatz eines Bordells. Das ist wertvolles Wissen. Man kann damit nämlich wahrscheinlich einen einfach zu identifizierenden Geheimdienstmitarbeiter erpressen. Insgesamt waren bei diesem Skandal 800.000 Autos betroffen und es gab ein Terabyte Daten. Da bieten sich genügend Chancen, so wertvolle Datenschätze zu finden.
Solche Probleme sind älter als Digitalcomputer: Die Niederlande hatten im Rahmen einer Volkszählung die Religionszugehörigkeit ihrer Bürger erfasst. Das haben die Nazis dann genutzt [3], um nach dem Einmarsch alle Juden zu deportieren.
Diese Datensätze sind so interessant, dass Geheimdienste versuchen werden, sie zu erbeuten. IT-Systeme kann man gegen solche Gegner nicht absichern. Ein Beispiel: Stuxnet [4]war ein Angriff auf die iranischen Ultrazentrifugen zur Herstellung von waffenfähigem Uran. Dabei sind unter anderem mehrere unbekannte Sicherheitslücken ("Zero-Day Exploits") in Windows genutzt worden. Gegen solche Angriffe kann man sich nicht schützen, weil die Sicherheitsprobleme unbekannt sind und es daher keine Gegenmaßnahmen geben kann. Das gilt sogar für Systeme von Atomanlagen, die wahrscheinlich nicht über Netzwerke wie das Internet zugreifbar sind und bei denen der physische Zugang wahrscheinlich kontrolliert wird.
Erwiesenermaßen sind auch die Daten unseres Parlaments nicht vor russischen Hackern sicher [5].
VW hat die Daten ungenügend gesichert, aber selbst wenn es das getan hätte: Das bedeutet nur, dass es schwieriger wird, auf die Daten zuzugreifen. Aber wenn ein Geheimdienst wirklich diese Daten haben will, wird ihm das gelingen.
Wichtig dabei: Es ist unwahrscheinlich, dass VW das einzige Unternehmen ist, das solche Daten speichert. Tesla sammelt beispielsweise Telemetriedaten und Videos und kann außerdem die Türen von Autos öffnen [6]. Diese Daten sind dann Menschen zugänglich, die einige für rechtsextrem [7]halten. Bei anderen Herstellern werden die Daten in autoritären Ländern gespeichert – sicher ebenfalls nicht optimal.
Aber nehmen wir an, dass die Daten nicht von vorneherein schon in problematischen Händen liegen, sondern "nur" gesichert werden müssen. Wie schwierig es ist, Daten zu sichern, zeigen Kryptowährungen. Wer den privaten Krypto-Schlüssel für ein Wallet hat, kann auf die entsprechenden Gelder zugreifen – egal, ob die Person das zu Recht tut oder das Geld gerade stiehlt. Daher müssen diese Schlüssel wirklich gut abgesichert werden. Es gibt aber eine Website [8], die ständig davon berichtet, dass wieder Kryptowährungsgelder verloren gegangen sind – meist viele Millionen, in einem Fall sogar 1,5 Milliarden US-Dollar [9]. Selbst wenn es also um bares Geld geht, können die Daten nicht ausreichend gesichert werden. Und auch in diesem Bereich sind Geheimdienste aktiv. Beispielsweise finanziert Nordkorea mit Krypto-Diebstählen seine Diktatur [10]und unter anderem sein Atomwaffenprogramm [11].
Absicherung der Daten ist also nicht die Lösung. Damit bleibt nur eine Lösung übrig: Diese Daten gar nicht zu erheben und zu speichern. Hier setzt Datenvermeidung und Datensparsamkeit [12] an: Beim Speichern von Daten muss man sich die Frage stellen, für welche Funktionalitäten sie erforderlich sind und nur die notwendigen Daten speichern. Wenn man sein Auto suchen will, benötigt man beispielsweise nur den aktuellen Ort, an dem das Auto steht. Dazu muss man keine historischen Daten speichern. Gegebenenfalls kann man sogar erst bei einer Anfrage Kontakt mit dem Auto aufnehmen und dann den aktuellen Standort des Autos ermitteln. Auf die Weise muss die Anwendung gar keine Daten speichern. Auf den ersten Blick ist nicht zu erkennen, wofür ein Unternehmen die historischen Bewegungsdaten eines Autos speichern will.
Zusätzlich könnte man Benutzerinnen und Benutzer fragen, ob bestimmte Funktionalitäten überhaupt aktiviert werden sollen. Dem BND ist es gegebenenfalls lieber, auf Komfortfunktionen eines Autos zu verzichten, als das Kompromittieren seiner Mitarbeiterinnen und Mitarbeiter zu vereinfachen. Das mag für andere anders sein. Wenn man aber nie klar fragt, sondern standardmäßig die Daten speichert und den Opt-out versteckt, macht es das schwierig, einen solchen Trade-off zu treffen und entmündigt die User.
Vor allem muss Schluss mit der Idee sein, dass Daten das neue Öl sind. Sonst ist das Speichern auf Vorrat für spätere Analyse völlig logisch und erzeugt Probleme wie den VW-Datenskandal.
Solche Phänomene gibt es auch an anderen Stellen: Will man wirklich die Gesundheitsdaten aller Deutschen sammeln und über ein Verfahren zugreifbar machen? Wie wertvoll sind diese Daten? Kann man sie dann überhaupt ausreichend schützen [13]?
Aber es gibt auch positive Beispiele: Bei der Corona-Warn-App ging es "nur" um Kontaktdaten, und dort hat man mit einer dezentralen Speicherung ein Konzept umgesetzt, das selbst der Chaos Computer Club "sehr gut" [14] fand.
Softwareentwicklerinnen und Softwarearchitekten müssen sich damit auseinandersetzen, was man mit den Daten aus ihrer Software anfangen kann. Ich fand es vor dem VW-Hack nicht offensichtlich, wie wertvoll diese Daten für interessierte Parteien sein können. Und das, obwohl schon zuvor Smartwatches die Position von Militärbasen verraten [15] haben. Daher müssen sich Entwicklungsteams immer die Frage stellen, ob man die Daten überhaupt sammeln will.
In den USA bekommt Elon Musks DOGE (das sogenannte "Department of Government Efficiency") Zugriff auf große Mengen von Daten [16]. Die Öffentlichkeit wird damit beruhigt, dass es nur um das Lesen der Daten ginge. Das zeugt von einer gewaltigen Naivität über den Wert von Daten. DOGEs eigene Website ist völlig unsicher [17]. Die Mitarbeiterinnen und Mitarbeiter versagen dabei, ihre eigenen Daten abzusichern [18]. Man muss also bezweifeln, ob Daten bei DOGE sicher sind. Es ist sicher eine gute Idee, sich auch die Frage zu stellen, was passiert, wenn gespeicherte Daten im Internet frei zugreifbar sind oder sie Rechtsextremisten oder einer undemokratischen Regierung in die Hände fallen.
Daten sind nur sicher, wenn man sie nicht speichert und erhebt. Developer-Teams sollten daher nur die Daten speichern, die unbedingt gespeichert werden müssen.
URL dieses Artikels:
https://www.heise.de/-10318961
Links in diesem Artikel:
[1] https://www.heise.de/meinung/Kommentar-zur-VW-Datenpanne-DSGVO-zeig-deine-Zaehne-10245938.html
[2] https://media.ccc.de/v/38c3-wir-wissen-wo-dein-auto-steht-volksdaten-von-volkswagen
[3] https://www.heise.de/hintergrund/Zahlen-bitte-Die-Lochkarte-Mit-80-Zeichen-wegweisend-in-die-EDV-4274778.html
[4] https://de.wikipedia.org/wiki/Stuxnet
[5] https://de.wikipedia.org/wiki/Hackerangriffe_auf_den_Deutschen_Bundestag
[6] https://www.heise.de/news/Explosion-in-Las-Vegas-Tesla-oeffnet-Cybertruck-aus-der-Ferne-und-sammelt-Videos-10223798.html
[7] https://de.wikipedia.org/wiki/Elon_Musk#Einordnung_im_politischen_Spektrum
[8] https://www.web3isgoinggreat.com/
[9] https://www.web3isgoinggreat.com/?id=bybit-hack
[10] https://edition.cnn.com/2025/02/24/politics/north-korean-hackers-crypto-hack/index.html
[11] https://apnews.com/article/technology-crime-business-hacking-south-korea-967763dc88e422232da54115bb13f4dc
[12] https://de.wikipedia.org/wiki/Datenvermeidung_und_Datensparsamkeit
[13] https://www.heise.de/news/38C3-Weitere-Sicherheitsmaengel-in-elektronischer-Patientenakte-fuer-alle-10220617.html
[14] https://www.tagesschau.de/inland/coronavirus-app-107.html
[15] https://www.gq-magazin.de/leben-als-mann/fitness/fitness-app-entdeckt-militaerbasen-180130
[16] https://www.telepolis.de/features/DOGE-und-Trump-Wie-Elon-Musk-den-US-Staat-umkrempeln-will-10281056.html
[17] https://www.derstandard.de/consent/tcf/story/3000000257396/zusammengeschustert-behoerden-website-von-doge-gehackt
[18] https://www.businessinsider.com/doge-nasa-google-calendar-public-2025-3
[19] mailto:rme@ix.de
Copyright © 2025 Heise Medien
(Bild: incrediblephoto / Shutterstock.com)
Künstliche Intelligenz könnte zu einem enormen Produktivitätssprung in der Softwareentwicklung führen. Welche Auswirkungen kann das haben?
Nehmen wir einmal an, dass wir es schaffen, die Produktivität in der Softwareentwicklung um eine Größenordnung – also um den Faktor zehn – zu verbessern. Um es ganz konkret zu machen, ein Gedankenexperiment: Eine Projektleiterin wacht morgens auf und weiß, dass in ihrem Projekt statt 100 Menschen nur 10 Menschen notwendig sind. Sie weiß auch, welche Menschen das sind. Das ist absolut sicher, so wie der Himmel blau ist.
Was wird die Projektleiterin nun tun?
Die erste Option wäre, das Projekt mit zehn Personen fortzusetzen und den restlichen 90 Personen andere Aufgaben zu geben oder sie gar zu entlassen. Diese Option umzusetzen ist schwierig, weil die Projektleiterin sich und anderen damit eingesteht, dass zu viele Menschen an dem Projekt gearbeitet haben. Außerdem ist das Management eines 100-Personen-Projekts prestigeträchtiger als die Leitung eines Projekts mit zehn Personen. Das Vorgehen birgt auch ein Risiko, weil man die Personen nicht so einfach wiederbekommt, wenn man doch eine sinnvolle Aufgabe für sie findet.
Eine andere Option ist, die zehn Personen an dem ursprünglichen Projekt arbeiten zu lassen und den anderen eine andere Aufgabe zu geben. Dazu könnte man den Scope des Projekts vergrößern. Das ist gegebenenfalls relativ einfach möglich, denn der Wunsch nach mehr Features ist eher die Regel. Oder man sucht für die Menschen ein anderes Projekt. Am Ende steht bei beiden Optionen mehr Wert für die Organisation und damit mehr Prestige für alle Beteiligten.
Vielleicht könnte man das Projekt auch durch die zusätzlichen Personen beschleunigen. Das erscheint aber schwierig, da mehr Menschen ein Projekt sogar verlangsamen können, weil Einarbeitung und mehr Kommunikation notwendig sind. Fred Brooks hat genau darauf in seinem Buch "The Mythical Man Month" hingewiesen.
Aber ist ein solches Gedankenexperiment überhaupt realistisch? Auch hier hat Fred Brooks eine Antwort: In seinem Paper "No Silver Bullet" [1] stellt er die Behauptung auf, dass keine einzelne Maßnahme alleine die Produktivität in der Softwareentwicklung um eine Größenordnung verbessern kann. Das lässt aber Raum dafür, dass eine Kombination von Maßnahmen dieses Ziel erreichen kann. Und außerdem ist es – so wie dieser Blog-Post – auch eine Hypothese, die er nicht weiter belegt.
Ein Grund, warum das Szenario vielleicht doch realistisch ist: Wie schon erwähnt, bedeuten mehr Menschen in einem Projekt mehr Prestige und somit gibt es einen Drang dazu, Projekte möglichst mit vielen Menschen durchzuführen. Das Gesetz von Parkinson besagt nun, dass alle verfügbaren Menschen auch an dem Projekt mitarbeiten werden. Da Softwareentwicklung viel Kommunikation bedeutet, kann diese Vielzahl an Menschen zu erschwerter Kommunikation führen. Weil die Kommunikation sich auch in der Architektur niederschlägt, bricht dann auch die Architektur zusammen. Die Beziehung zwischen Kommunikation und Architektur geht auf Conway und sein Gesetz zurück. Er hat auch die These von aufgeblasenen Projekten mit schlechter Kommunikation und am Ende schlechter Architektur aufgestellt, die bereits Thema eines anderen Blog-Posts [2] war.
Dann kommt man aber mit einer sauberen Architektur, weniger Menschen und damit weniger Kommunikation und Kommunikationsproblemen vielleicht genauso schnell zum Ergebnis, sodass das Gedankenexperiment vielleicht doch nicht ganz unrealistisch ist.
Motivator für das Gedankenexperiment ist aber eine andere Entwicklung: Es kann sein, dass wir durch künstliche Intelligenz bei der Produktion von Code deutlich effizienter werden, wie ein anderer Blog-Post [3] diskutiert hat. Dann ist die Frage, was bei einer Verbesserung von Produktivität um einen Faktor 10 passiert, sehr relevant.
Das Gedankenexperiment legt den Verdacht nahe, dass selbst bei einem solchen Fortschritt eher mehr Software produziert wird und in der Konsequenz Software auch für Bereiche genutzt wird, für die es sich im Moment noch nicht lohnt.
Tatsächlich gibt es in der Ökonomie für dieses Phänomen: Rebound-Effekt [4]. Wenn beispielsweise Autos effizienter werden, werden sie für mehr Fahrten genutzt, sodass am Ende nicht etwa der Verbrauch sinkt, sondern gegebenenfalls sogar steigt. Vielleicht führt KI zu einem ähnlichen Effekt: Softwareentwicklung wird damit zwar effizienter, aber Software wird dann auch für andere Einsatzzwecke genutzt, sodass am Ende der investierte Aufwand derselbe bleibt. Tatsächlich unterstützt Software immer mehr Bereiche und KI könnte diesen Trend dann noch verstärken.
Im Extremfall können Menschen Software entwickeln, denen das technische Skillset eigentlich fehlt. Auch dieses Versprechen gab es schon mehrfach, mit Technologien wie COBOL, aber auch Low- oder No-Code. Aber selbst wenn KI hier erfolgreich ist: Andere Branchen zeigen, welche Effekte solche Disruptionen haben. Mit Desktop-Publishing können im Vergleich mit den Achtzigerjahren nun viel mehr Menschen Druckerzeugnisse erstellen, aber die Qualität ist eher schlechter geworden und Profis haben immer noch ihr Betätigungsfeld.
Das mag nun so wirken, als sei die Zukunft der Softwarebranche auch gegen KI abgesichert. Aber natürlich ist die Zukunft schwer vorhersagbar. Man hätte auch argumentieren können, dass die aktuelle Krise am IT-Markt nur ein Vorbote von dem ist, was KI anrichten wird. Die Zukunft ist offen.
Selbst eine Verzehnfachung der Produktivität in der Softwareentwicklung, wie sie KI vielleicht hervorbringt, bedeutet nicht unbedingt, dass weniger Menschen in dem Bereich arbeiten werden, sondern vielleicht eher, dass Software für noch mehr Einsatzzwecke genutzt wird.
URL dieses Artikels:
https://www.heise.de/-10189960
Links in diesem Artikel:
[1] https://software-architektur.tv/2024/02/02/folge201.html
[2] https://www.heise.de/blog/Beten-wir-Komplexitaet-an-4170914.html
[3] https://www.heise.de/blog/KI-in-der-Softwareentwicklung-Ueberschaetzt-9336902.html
[4] https://de.wikipedia.org/wiki/Rebound-Effekt_(%C3%96konomie)
[5] https://genai.bettercode.eu/?wt_mc=intern.academy.dpunkt.konf_dpunkt_bcc_genai.empfehlung-ho.link.link
[6] https://genai.bettercode.eu/?wt_mc=intern.academy.dpunkt.konf_dpunkt_bcc_genai.empfehlung-ho.link.link#programm
[7] mailto:rme@ix.de
Copyright © 2024 Heise Medien
(Bild: Jose HERNANDEZ Camera 51/Shutterstock.com)
Softwareentwicklungsteams sind soziale Systeme. Auch andere Primaten bilden solche sozialen Systeme. Was können wir von den anderen Primaten lernen?
Wie Menschen soziale Organisationen bilden, hat Auswirkungen auf unsere Branche: So gibt es die Frage, wie groß ein Team oder eine Firma zu sein hat. Als Orientierung dient oft die Dunbar-Zahl [1] von 150. Sie soll angeben, mit welcher Gruppengröße Menschen typischerweise noch gut zurechtkommen. Leider ist diese Darstellung schlicht falsch. Dunbars wissenschaftliche Publikation [2] sagt etwas völlig anderes.
Er untersuchte nicht menschliche Primaten, umgangssprachlich fälschlicherweise oft als "Affen" bezeichnet. Das Verhältnis des Volumens ihres Neocortex zum Rest des Gehirns hängt mit der Gruppengröße zusammen, die diese Primaten bilden. Aus diesen Daten extrapoliert Dunbar eine Gruppengröße für Menschen von 147,8. Wie in der Wissenschaft üblich, hat der Wert eine Streuung. Mit 95 % Wahrscheinlichkeit liegt der Wert im Bereich von 100,2 bis 231,1. Ein anderes Paper [3] ergibt völlig andere Bereiche für die Zahl mit 95-%-Konfidenzintervallen im Bereich 3,8 bis 292,0. Das Paper stellt noch einige andere Datenanalysen dar, die aber alle ein Konfidenzintervall von niedrigen einstelligen Werten bis hin zu einigen Hundert aufweisen. Wenn man dieses Paper betrachtet, hat die Zahl keinen praktischen Nutzen.
Aber Dunbar geht es auch nicht so sehr um die Zahl: In Gruppen nutzen Primaten gegenseitige Fellpflege (Grooming), um unter anderem Parasiten zu entfernen, aber auch um sozialen Zusammenhalt zu stärken. Dunbar stellt ein Verhältnis zwischen der Zeit her, die für Fellpflege notwendig ist, und der Größe der Gruppe der Primaten. Größere Gruppen benötigen mehr Fellpflege. Daraus, so Dunbar, würde sich für Menschen ein Zeitaufwand ergeben, der nicht darstellbar ist. Laut Dunbar haben Menschen daher Sprache entwickelt, um effizienter sozialen Zusammenhalt herzustellen. Sprache ist also nicht, wie andere Wissenschaftler und Wissenschaftlerinnen behaupten, zur Koordinierung beim Jagen oder Herstellen von Werkzeugen entstanden, sondern zur Pflege sozialer Beziehungen.
Mit anderen Worten: Dunbars zentrale These ist nicht die Größe der Gruppe, sondern dass menschliche Sprache sich zum Stärken sozialer Beziehungen entwickelt hat.
Die Dunbar-Zahl von 150 ist nur die extrapolierte maximale Größe von Menschengruppen, die Sprache als einen der gemeinsamen Fellpflege vergleichbaren Prozess nutzt. Er spricht von Clan / Village. Daneben nennt er noch andere Gruppen: Bands (Banden) mit 30 bis 50 Personen und Tribes (Stämme) mit 1000 bis 2000 Personen.
Dementsprechend diskutiert Dunbars Paper zahlreiche Beispiele für menschliche Gruppen sehr unterschiedlicher Größe. Gruppen mit einer Größe deutlich anders 150 gehören dann eben zu einer anderen Kategorie, so Dunbar. Seine These ist also definitiv nicht die Größe der Gruppen, sondern die Mechanismen der Gruppe, um sich selbst zu erhalten – und das schreibt er auch selbst so.
Besonders interessant: Dunbar sieht die Gruppen im Militär als eine Bestätigung seiner These, denn es soll dort auch Gruppen einer Größe von 100 bis 200 Menschen geben. Aber natürlich gibt es im Militär auch wesentlich kleinere Gruppen wie einen Trupp (2 bis 8 Soldaten bei der Bundeswehr) oder größere Gruppen wie ein Bataillon (300 bis 1200 Soldaten), die er dann nicht weiter betrachtet.
Zu dem Paper gibt es umfangreiche Kritik anderer Wissenschaftler, sodass praktisch jeder Teil des Papers umstritten ist. Beispielsweise gibt es bezüglich der Gruppengröße Hinweise auf Fission-/Fusion-Verhalten unter Primaten. Das sind Gruppen, zu denen Individuen hinzustoßen und sich dann wieder entfernen. Individuen können etwa an einem Ort gemeinsam schlafen, aber den Tag getrennt verbringen. Solche Gruppen sind also nur temporär. Spezies mit solchem Verhalten benötigen aber nur wenig Zeit für die gemeinsame Fellpflege und sind teilweise deutlich größer. Offensichtlich können Primaten also auch ohne komplexe menschliche Sprache große Gruppen bilden.
Für die Organisation von menschlichen Teams kann man also aus der Dunbar-Zahl nichts lernen. Dunbar selbst sagt ja, dass es menschliche Gruppen praktisch beliebiger Größe geben kann. Man muss für diese Aussage nicht einmal auf die umfangreiche Kritik zurückgreifen.
In den Kritiken finden sich noch weitere interessante Punkte. So ist es beispielsweise überhaupt nicht klar, warum die Anzahl Menschen, die ein Mensch in irgendeiner Form kennt, eine Gruppengröße beeinflusst. Wenn wir also nur eine bestimmte Anzahl Menschen kennen und mit ihnen regelmäßig sprechen, dann kann eine Gruppe dennoch deutlich größer sein. Es reicht ja, wenn man gemeinsam koordiniert handelt. Dank Sprache können Menschen sich auch in großen Dimensionen bis hin zu Nationen oder darüber hinaus koordinieren. Dass sich Menschen unterschiedlich gut kennen und vertrauen, sollte eigentlich jedem klar sein. Im Projektalltag nutzt man das auch aus. Statt einer Person eine Information direkt zu geben, bittet man eine dritte Person darum, weil das Vertrauensverhältnis zwischen diesen beiden Personen besser ist.
Für mich ist die Fehlinterpretation der Dunbar-Zahl ein Hinweis auf ein grundlegendes Problem: Komplexes menschliches und soziales Verhalten wird simplifiziert. Am Ende steht eine Zahl mit der idealen Größe einer Gruppe. Das ist eine einfache Regel, an die man sich halten kann.
Eigentlich sollte die Intuition jedem etwas anderes sagen. Denn jeder weiß durch das eigene Leben, dass Menschen in unterschiedlichen Gruppen agieren können – im privaten und im beruflichen Kontext: die Firma, der Verein, die Nachbarschaft, die Freunde, die Familie. Die Gruppen sind unterschiedlich groß. Für besonders große Gruppen gibt es Hierarchien wie im Militär, aber auch in Unternehmen mit Team, Abteilungen, Standorten usw.
Diese Gruppen existieren oft nicht lange. Beispielsweise bei einem Training oder beim ersten Consulting-Termin müssen Trainer und Beraterinnen mit einer Gruppe zusammenarbeiten, die sie nie zuvor gesehen haben – und das funktioniert. Das ist sicher eine andere Gruppe, mit einer anderen Art von Beziehung als die eigene Familie, aber eine solche Gruppe hat auch andere Ziele.
Nun kann man argumentieren, dass unter anderem das Vertrauen erst mit der Zeit wächst. Aber auch Vertrauen kann schnell gebildet werden: Wird ein Patient ins Krankenhaus eingeliefert, wird er der behandelnden Ärzt:in im Extremfall sogar sein Leben anvertrauen, ohne die Person vorher jemals gesehen zu haben.
Sicher kann man Dunbars Forschung als Inspiration nutzen, um über Mechanismen für die Stärkung des Zusammenhalts von Gruppen nachzudenken. Dunbars These ist, dass Sprache nur entstanden ist, um sozialen Zusammenhalt zu stärken, und er präsentiert dazu Statistiken, wie viel Zeit mit dem Gespräch über soziale Beziehung und Gossip (Tratsch) verbracht wird. Maßnahmen zum Stärken des Zusammenhalts, beispielsweise durch ungezwungene Gespräche, können sinnvoll sein. Wo gibt es für ein Team ein solches Forum? Das müssen nicht erzwungene Team-Bondings sein, sondern ein regelmäßiges gemeinsames Mittagessen kann eine solche Funktion gut ausfüllen.
Die Dunbar-Zahl sagt nichts über die mögliche Größe von Teams oder Firmen aus. Sie können eine beliebige Größe haben und unterschiedlich strukturiert sein. Die Fehlinterpretation der Zahl deutet darauf hin, dass unsere Branche für Vereinfachungen anfällig ist, die der Intuition widersprechen. Teams benötigen einen Mechanismus, um einen sozialen Zusammenhalt herzustellen.
URL dieses Artikels:
https://www.heise.de/-9825599
Links in diesem Artikel:
[1] https://de.wikipedia.org/wiki/Dunbar-Zahl
[2] https://www.cambridge.org/core/journals/behavioral-and-brain-sciences/article/abs/coevolution-of-neocortical-size-group-size-and-language-in-humans/4290FF4D7362511136B9A15A96E74FEF
[3] https://royalsocietypublishing.org/doi/10.1098/rsbl.2021.0158
[4] mailto:rme@ix.de
Copyright © 2024 Heise Medien
(Bild: LanKS/Shutterstock.com)
Agilität ist angetreten, produktiver Software zu entwickeln. Eine Studie zeigt aber mehr Fehlschläge. Das sagt mehr über unsere Branche aus als über Agilität.
Eine Studie [1] will zeigen, dass agile Softwareentwicklung angeblich eine 268 Prozent höhere Chance für Fehlschläge mit sich bringt. So ein massiver Nachteil muss eigentlich dazu führen, dass alle sofort aufhören, überhaupt irgendwelche Projekte agil durchzuführen.
Wie kommen die Zahlen zustande? Die Studie stellt zunächst fest, dass folgende Faktoren den Erfolg von Softwareentwicklungsprojekten verbessern:
Keinen erheblichen Einfluss hatte hingegen, ob Menschen an einem oder mehreren Projekten gleichzeitig arbeiten.
Die Studie definiert agile Entwicklung als Projekte, bei denen Folgendes gilt:
Zusammen führt das zu 268 Prozent mehr Fehlschlägen und 65 Prozent gescheiterten Projekten. Das Zahlenmaterial ist auch mit passenden statistischen Werten ausgestattet und wirkt daher überzeugend.
Das erste Problem der Studie ist die fehlende Definition von "Fehlschlag". Ein mögliches Kriterium wäre, dass die Projekte nicht im Budget geliefert wurden. Das ist aber ein eigentümliches Ziel für ein Individualsoftwareprojekt. Wenn man Software möglichst billig haben will, sollte man sie nicht selbst entwickeln, sondern Standardsoftware kaufen. Das ist sinnvoll für Bereiche, in denen man die Flexibilität einer eigenen Implementierung nicht benötigt. Mir wäre beispielsweise nicht klar, warum man eine Finanzbuchhaltung selbst implementieren würde.
Vielleicht sind mit höheren Kosten ein höherer Wert verbunden, weil mehr Features umgesetzt und so vielleicht sogar mehr Umsatz und Gewinn erzielt werden? Ist das Projekt dann ein Fehlschlag?
Eine weitere Möglichkeit, "Fehlschlag" zu definieren wäre, wenn der Auftraggeber am Ende des Projekts vom Ergebnis enttäuscht ist. Das ist vielleicht sinnvoll, aber kein rationales Kriterium. Kunden können aus den unterschiedlichsten Gründen enttäuscht werden. Unterschiedliche Stakeholder können unterschiedlich zufrieden mit dem Ergebnis sein.
Die Definition von "Fehlschlag" ist keine Frage ohne praktische Auswirkungen. Ich habe selbst in Projekten mitgearbeitet, die offiziell ein Erfolg waren, aber subjektiv erhebliche Probleme hatten oder vorab definierte Projektziele nicht erreicht haben. Es geht schlimmer: Einige Projekte haben gar keine echten Projektziele – wie soll man dann über einen Fehlschlag oder Erfolg entscheiden?
Eigentlich könnte man jetzt schon damit aufhören, die Studie genauer zu betrachten. Aber die Studie hat noch viele weitere Probleme.
Die Studie behauptet, dass es hilfreich ist, wenn Requirements vor dem Start des Projekts bekannt sind, die Spezifikation vollständig ist und signifikante Änderungen spät im Projekt unterbleiben. Ich muss gestehen: Mein Erstaunen darüber wie auch über die anderen Ergebnisse der Studie hält sich in engen Grenzen. Mehr Informationen am Anfang und weniger Änderungen im Verlauf des Projekts machen Projekten das Leben sicher einfacher. Man könnte so ein Projekt als langweilig bezeichnen. Aus der Sicht der Umsetzer ist das super, weil das Projekt eben mit höherer Wahrscheinlichkeit erfolgreich ist. Aus Sicht der Auftraggeber erscheint es aber unwahrscheinlich, dass ein solches Projekt einen hohen Wert hat. Wenn man etwa einen neuen Markt schneller als der Wettbewerb mit einem neuen digitalen Produkt besetzen will, sind vermutlich die Requirements nicht klar, die Spezifikation unvollständig und es werden sich auch spät im Projekt Änderungen ergeben, weil schlicht nicht klar ist, was die Kunden genau wollen und wie der Markt aussieht. Niemand kann das wissen. Die Kunden greifen erst zu, wenn ihnen das Projekt gefällt.
Genau in dem Fall kann Agilität ihre Stärken ausspielen. Ich glaube sofort, dass solche Projekte öfter von der ursprünglichen Planung abweichen und das kann man einen Fehlschlag nennen. Aber was ist die Konsequenz? Solche Projekte einfach nicht angehen und eine solche Markt-Chance nicht ergreifen? Maßnahmen ergreifen, um doch Stabilität vorzutäuschen, die dann aber das Projekt behindern?
Anders gesagt: Gerade die Projekte, die laut der Studie öfter fehlschlagen, sind vielleicht die Projekte, die einen besonders hohen Wert generieren.
Angeblich orientiert sich die Definition von Agilität aus der Studie am agilen Manifest. [2] Also sollte das agile Manifest irgendwo etwas enthalten im Sinne von: "Wenn am Anfang des Projekts Anforderungen klar sind, und eine vollständige Spezifikation vorliegt, lösche dieses Dokument und sorge dafür, dass sich niemand an die Anforderungen und die Spezifikation erinnert – sonst genügt das Projekt nicht diesem Manifest." Und ebenso müsste da irgendwo "Wenn sich im Projekt später keine signifikanten Änderungen ergeben, dann erfinde welche – sonst genügt das Projekt nicht diesem Manifest" stehen. Ich habe nachgeschaut: Das steht nicht im agilen Manifest und es gibt auch keinen Absatz, der sich so interpretieren ließe. Im Gegenteil: Das agile Manifest wägt Optionen wie das Befolgen eines Plans und das Reagieren auf Änderungen ab – und legt den Fokus auf eins, in dem Beispiel das Reagieren auf Änderungen, ohne dass die andere Option als unwichtig bewertet wird – nur eben als weniger wichtig. Auf eine Änderung zu reagieren erscheint tatsächlich sinnvoller, als an dem festen Plan festzuhalten, der die Änderung noch gar nicht betrachtet haben kann.
Die Studie basiert übrigens auf einer Umfrage unter 600 Software Engineers. Umfragen können immer nur das subjektive Bild der befragten Person abbilden – in diesem Fall also die der Software Engineers. Da eine Softwareentwicklung eine wirtschaftliche Investition ist, wäre es sinnvoll andere Gruppen, insbesondere unterschiedliche Stakeholder ebenfalls zu befragen. Schließlich geben sie die Projekte in Auftrag. Wer könnte also besser bewerten, ob das Projekt wirklich ein Fehlschlag ist.
Und die Studie lässt noch eine Frage unbeantwortet: Wie viele Projekte haben denn klare Requirements? 10 Prozent? 25 Prozent? 90 Prozent? Man kann aus der Studie nur entnehmen, dass es eine genügend große Anzahl sein muss, um statistisch signifikante Aussagen zu treffen. Wenn sehr viele Projekte unklare Requirements haben, wäre das ein Hinweis auf ein wichtiges Problem. Ob und wie man es lösen kann, ist dann die nächste Frage – und die ist nicht so einfach zu beantworten. Requirements kann man sich ja nicht einfach wünschen, sondern gegebenenfalls sind sie wie erwähnt prinzipienbedingt unklar.
Eigentlich ist die Studie keinen Blogpost wert. Sie ist ein durchsichtiges Manöver, um agile Softwareentwicklung zu diskreditieren und einen anderen Ansatz zu promoten. Aber die Studie hat dennoch Einfluss – mir sind in zwei unterschiedlichen Kontexten Hinweise auf die Studie untergekommen. Das ist nachvollziehbar: 268 Prozent ist eine krasse Zahl und das Ergebnis ist überraschend, weil Agilität ja eigentlich mehr Erfolg erreichen sollte. Da muss man einfach hineinschauen! Wenn man das wirklich tut, wird schnell klar, was für ein Unsinn da steht. Ein YouTube-Video [3] hat die Zahl genutzt, um andere Aspekte von Agilität zu kritisieren, also nicht die Probleme mit Requirements, die die Studie erläutert. Unabhängig davon, ob die Kritik berechtigt ist: Das Video nutzt die absurde Zahl aus der Studie, um Aufmerksamkeit zu generieren.
Wenn wir in unserer Branche so vorgehen, dürfen wir uns nicht wundern, wenn wir nicht lernen, was wirklich hilft und so kein Fortschritt erzielt wird. Dabei wird die kritische Arbeit mit Quellen schon in der Schule gelehrt.
Ob Agilität nun "gut" oder "schlecht" ist, können wir mit der Studie nicht beantworten. Aber: Dass wir Software in Iterationen erstellen müssen, hat sich in der Praxis historisch sehr früh gezeigt – im Prinzip als Menschen angefangen haben, Software in Teams zu entwickeln. Und zwar auch, wenn man anders als in agilen Projekten relativ stabile Anforderungen hat. Das wird klar, wenn man Pionieren und Pionierinnen wie Prof. Christiane Floyd zuhört [4]. Zu dem Thema habe ich auch einen Vortrag [5] gehalten. Dass es Projekte gibt, die gut daran tun, beispielsweise auf Änderungen zu reagieren, statt einem Plan zu folgen, sollte auch klar sein. Das wirkliche Problem ist vielleicht, dass Agilität als Begriff mittlerweile verbrannt ist, weil in der Realität "agile" Prozesse eingeführt werden, die nicht den ursprünglichen Ideen entsprechen und auch nicht sonderlich hilfreich sind.
Unsere Branche ist anfällig für tendenziöse Studien. Das ist schade. Krasse Behauptungen erzeugen Aufmerksamkeit.
URL dieses Artikels:
https://www.heise.de/-9810522
Links in diesem Artikel:
[1] https://www.engprax.com/post/268-higher-failure-rates-for-agile-software-projects-study-finds
[2] https://agilemanifesto.org/iso/de/manifesto.html
[3] https://www.youtube.com/watch?v=gSVBWvoNJ-s
[4] https://software-architektur.tv/2021/07/09/folge66.html
[5] https://software-architektur.tv/2024/04/02/folge211.html
[6] mailto:rme@ix.de
Copyright © 2024 Heise Medien
(Bild: Login/ Shutterstock.com)
Das Ende ist nah: Bald wird KI die Softwareentwicklung übernehmen. Das ist übertrieben und zeigt, wie unklar ist, worum es Softwareentwicklung wirklich geht.
Zunächst: KI hilft beim Produzieren von Code. Das ist zweifellos ein signifikanter Fortschritt und wird vieles ändern. Jeder kann die zahlreichen Werkzeuge ausprobieren und sich davon selber überzeugen, wie mächtig diese Werkzeuge sind.
Aber auch wenn es zunächst paradox erscheint: Code zu produzieren, ist nicht das wesentliche Problem bei der Entwicklung von Software. Das wirkliche Problem ist, herauszufinden, welcher Code geschrieben werden muss. Dazu müssten die fachlichen Anforderungen bekannt sein. Anforderungen sind in der Praxis aber meist viel zu unklar, um daraus erfolgreich Software entwickeln zu können. Selbst wenn sie klar scheinen, stellt sich oft später im Prozess heraus, dass es doch Missverständnisse gab. So kommt der Interaktion mit Domänenfachkundige eine zentrale Rolle zu. Entwickler und Entwicklerinnen müssen so viel über die Domäne lernen, dass sie die passende Software für die fachlichen Fragestellungen entwickeln können.
Außerdem ändern sich die Anforderungen. Durch die Entwicklung der Software, den Einsatz der neuen Software und den damit zusammenhängenden Diskussionen reflektieren User und Domänenfachleute über die Nutzung der Software und kommen so zu neuen Anforderungen. Auch an diesem Prozesse müssen Developer teilnehmen, um zu verstehen, was zu entwickeln ist. Zudem können sie Feedback geben, falls Anforderungen besonders leicht oder schwierig umsetzbar sind - oder Änderungen an den Anforderungen die Umsetzung deutlich vereinfachen.
Bei den Anforderungen erkennt man schon die Bedeutung des Faktors Mensch. Er ist ebenfalls zentral: Softwareentwicklung findet immer im Team statt. So ein Team besteht üblicherweise aus mehreren Developern, aber auch andere Rollen wie UX-Experten, Architektinnen oder POs. Damit kommt der Kommunikation eine zentrale Rolle bei der Entwicklung zu: Aufgaben müssen verteilt und organisiert werden. Und die Organisation beeinflusst auch die Software: Das Gesetz von Conway besagt, dass die Architektur der Software den Kommunikationsbeziehungen des Teams entspricht. Wenn das soziale Gefüge so einen starken Einfluss auf die Entwicklung hat, dann sind in diesem Bereich auch die zentralen Herausforderungen. Und so haben die meisten Probleme in den Projekten auch ihre Ursache in der menschlichen Ebene. Hier kann KI nicht helfen.
Es wäre möglich, dass durch KI die Produktivität so sehr erhöht wird, dass eine Person statt eines Teams für ein Softwareprojekt ausreicht und so der Faktor Mensch weniger wichtig wird. Das erscheint unwahrscheinlich. Und die Interaktion mit Menschen zur Klärung von Anforderungen ist immer noch notwendig. Außerdem gab es auch schon vor den KI-Tools Fortschritte bei der Produktivität. Das hat aber nicht zu kleineren Teams geführt. Die Größe der Software-Teams steigt subjektiv eher, um noch kompliziertere Systeme zu realisieren und noch mehr Bereiche mit Software zu unterstützen. Wenn sich der Trend fortsetzt, werden wir mit KI ebenfalls noch komplexere Systeme bauen und nicht etwas kleinere Teams.
Das Produzieren von Code zu vereinfachen, ist auch nichts Neues. Im Gegenteil: Es gibt eine lange Historie von technischen Ansätzen, um Softwareentwicklung zu vereinfachen. Typischerweise heben diese Ansätze die Entwicklung auf eine neue Abstraktionsebene. Begonnen hat Softwareentwicklung damit, dass man Binärcode direkt in den Speicher der Computer geschrieben hat. Assembler hat dann Befehle definiert, die den Binärcodes entsprechen, aber einfacher zu merken und zu verstehen sind. So wurde vom Binärcode abstrahiert. Hochsprachen führen Konzepte ein, die von Assembler abstrahieren und mit denen Algorithmen und Logik noch einfacher ausdrückbar ist. Parallel sind Aufgaben in die Infrastruktur gewandert und wurden so für Entwicklungsteams: Betriebssysteme und Datenbanken bieten Lösungen für Persistenz, Speicher- und Prozessverwaltung. Libraries und Frameworks bieten auf Code-Ebene fertige Lösungen für typische Teilfunktionalitäten an. Und die Cloud [2]bietet eine Abstraktion über viele vorhandene Infrastrukturelemente wie Datenbanken oder Computer, sodass Infrastruktur für Projekte einfacher umgesetzt werden kann.
KI ist ein weiterer Schritt auf diesem Weg. Tatsächlich sind die Fortschritte so beeindruckend, dass man sicher von einer neuen Abstraktionsstufe sprechen muss. Es gibt prototypische Werkzeuge wie GPT Engineer [3], die eine ganze Anwendung anhand einer Spezifikation erstellen und dabei Rückfragen stellen, falls Anforderungen unklar sind (Video [4]). Nur wie zuvor erwähnt: Softwareentwicklung mit klaren Anforderungen ist nicht das Problem. Also wird der weniger problematische Teil der Softwareentwicklung durch KI vereinfacht und nicht der Kern.
KI führt sogar zu Gefahren: Eine Studie [5] hat das Verhalten von Entwicklerinnen und Entwicklern beim Schreiben von sicherheitsrelevantem Code ausgewertet und kommt zu dem Schluss, dass diejenigen mit KI-Unterstützung ihre Lösungen als sicherer einstufen als solche ohne. Nur ist in der Realität genau das Gegenteil der Fall: Ihr Code ist weniger sicher. Und das ist offensichtlich gefährlich: Es geht eben nicht darum, Code zu produzieren, sondern ein Problem soll gelöst werden. Und sicherheitsrelevante Software mit Sicherheitsprobleme schafft in Wirklichkeit neue Probleme. Gerade der Unterschied zwischen der subjektiven Bewertung und der objektiven Realität kann verheerend sein: Man glaubt, die Software sei sicher. Das stimmt aber nicht. Sicherheitslücken sind nur leider anders als fachliche Fehler oder Performance-Probleme nicht offensichtlich und so kann der Schaden ganz im Verborgenen entstehen. Solche Risiken zu managen und Lösungen zu entwerfen, welche die Qualitäten beispielsweise bei Sicherheit bieten, kann eine KI ebenfalls kaum lösen. Au!
Das nächste Problem: Es geht meist nicht um das Produzieren von Code, sondern um das Ändern. Das bedeutet auch, dass Entwicklerinnen und Entwickler vorhandenen Code lesen und verstehen müssen, um ihn sinnvoll zu ändern. Offensichtlich wird Code am Anfang einmal geschrieben, aber öfter geändert und damit auch gelesen. Dann ist das größere Optimierungspotential aber nicht beim einmaligen Produzieren, sondern beim Lesen, Verstehen und Ändern, das viel öfter stattfindet. Aber auch in diesem Bereich kann KI helfen: Tatsächlich kann man ChatGPT darum bitten, Code zu erklären. Dabei geht es eher um kleinere Codeschnipsel. Aber das Potenzial ist sicher groß: Gerade für Legacy-Code könnte eine speziell auf ein System trainierte KI ein interessantes Werkzeug sein, um das Verständnis des Systems zu verbessern und damit Änderungen zu vereinfachen.
Das Problem der Softwareentwicklung ist nicht, Code zu produzieren, sondern zu verstehen, was implementiert werden soll. Die Produktivitätsvorteile durch KI lösen dieses Problem nicht. KI wird Softwareentwicklung wesentlich ändern, aber nicht das Kernproblem lösen.
URL dieses Artikels:
https://www.heise.de/-9336902
Links in diesem Artikel:
[1] https://heise-academy.de/schulungen/githup?wt_mc=intern.academy.ix.ws_github.newsticker.link.link
[2] https://www.heise.de/blog/Die-Cloud-Eine-Komponentenbibliothek-3354034.html
[3] https://github.com/AntonOsika/gpt-engineer
[4] https://www.youtube.com/watch?v=FPZONhA0C60&t=440s
[5] https://arxiv.org/abs/2211.03622
[6] mailto:rme@ix.de
Copyright © 2023 Heise Medien
(Bild: Pixels Hunter/Shutterstock.com)
Softwarearchitektur beeinflusst den Erfolg eines Projekts erheblich. Aber ausgerechnet "gute" Entwickler und Entwicklerinnen können Feinde der Architektur sein.
Warum ist Softwarearchitektur überhaupt so wichtig? Sie hilft uns, große Systeme zu implementieren. Durch die Strukturierung von Code in Module können wir sicherstellen, dass Entwicklerinnen und Entwickler für Änderungen nur das jeweils zu ändernde Modul im Detail verstehen müssen. Von anderen Modulen ist nur oberflächliches Wissen notwendig, beispielsweise über die Schnittstelle. Dieses Prinzip wird als "Information Hiding" bezeichnet: Details sind in den Modulen versteckt und können mit wenig Einfluss auf andere Module geändert werden. So lassen sich Module idealerweise in Isolation verstehen und ändern. Wenn die Architektur besonders gelungen ist, können Entwicklerinnen also mit wenig Wissen und daher besonders einfach Änderungen an der Software vornehmen.
Unter "guten" Developern möchten wir uns hier Personen vorstellen, die auch komplizierte Systeme verstehen und weiterentwickeln können. Solche Personen können auch mit Architektur-Fehlschlägen umgehen, bei denen Änderungen nicht so einfach sind und gegebenenfalls schwer zu verstehende Auswirkungen haben – manchmal auf völlig andere Stellen des Systems. Vielleicht finden sie es sogar intellektuell herausfordernd, sich mit solchen Problemen zu beschäftigen, und es macht ihnen Spaß. Außerdem sorgen diese Umstände nicht nur für einen sicheren Job, sondern auch für Prestige. Schließlich sind diese Personen oftmals die Einzigen, die wichtige Systeme noch ändern können und so für das Geschäft einen sehr einen hohen Wert haben.
Hinweise auf ein solches Verständnis von "guten" Entwicklern und Entwicklerinnen finden sich auch anderswo: Wer beispielsweise im Code die Feinheiten von einer Programmiersprache wie Java nutzt, die in einer Zertifizierung abgefragt werden, erstellt nicht besonders einfach zu verstehenden und zu ändernden Code, sondern gerade solchen, der die Features voll ausreizt und sich auf spezielle Eigenschaften der Sprache verlässt. Der Code ist besonders schwierig zu verstehen und damit zu ändern. Dennoch ist eine solche Zertifizierung als ein Hinweis auf das Können der Developer anerkannt. Wer also besonders unleserlichen Code schreiben oder lesen kann, gilt demnach als besonders gut.
Solche Entwickler und Entwicklerinnen mögen vielleicht "akademische" Architekturansätze nicht und bevorzugen eine "pragmatische" Herangehensweise. Schließlich profitieren sie von der Situation sogar. Bis zu einer gewissen Kompliziertheit funktioniert das ja auch. Bei "wirklich guten" Developern führt das bis zu einer erschreckend hohen Kompliziertheit. Sie verstehen dann Systeme, die für Außenstehende ein Mysterium sind. Dann fällt die Arbeit der Softwarearchitekten und -architektinnen aber vermutlich nicht auf fruchtbaren Boden. Schließlich kann man das System ja weiterentwickeln – warum es also besser strukturieren? In der Tat kann es passieren, dass die Architektin schließlich sogar das Team verlässt, um eine andere Position zu finden, wo ihre Mühen sinnvoller scheinen. Und daher sind "gute" Developer die natürlichen Feinde der Softwarearchitektur.
Das Problem ist das Verständnis, wann Entwicklerinnen als "gut" im Sinne von kompetent gelten. Natürlich müssen Entwickler Technologien verstehen. Es ist sicher vorteilhaft, wenn sie auch mit kompliziertem Code umgehen können, aber sie sollten solche Situationen vermeiden und auf keinen Fall auf sie hinarbeiten. Wirklich gute Developer arbeiten am liebsten an einfachem Code. Sie haben gerade eine Aversion gegen komplizierten Code – und dann haben Entwicklerinnen und "saubere" Architektur dasselbe Ziel.
Wir können in Projekten eine Umgebung schaffen, in der sich "saubere" Architektur durchsetzen kann. Dazu sollten wir Developer nicht beglückwünschen, weil sie eine komplizierte Änderung ganz alleine umgesetzt haben. Stattdessen sollte die Frage im Vordergrund stehen, wie sich solche komplizierten Änderungen in Zukunft vermeiden lassen und wie mehr Personen dazu befähigt werden können, solche Änderungen durchzuführen. Um die Entwicklung guter Softwarearchitektur zu fördern, sollten wir positive Arbeitsweisen belohnen und negative korrigieren. Statt den Fokus auf das individuelle Können eines Entwicklers beim Umgang mit kompliziertem Code zu legen, sollten wir uns auf die Qualität des Codes und die Umsetzung der Architektur konzentrieren.
Wichtig ist auch ein breites Interesse an Themen, die nicht mit den rein technischen Aspekten der Entwicklung zu tun haben. Das hilft dabei, die Domäne, die Anforderungen sowie die Nutzerinnen und Nutzer zu verstehen und die richtigen Features zu implementieren. Dazu muss man aber ein originäres Interesse an der Domäne und der Fachlichkeit haben – Personen mit einem breiten Interessenspektrum fällt das leichter.
Softwarearchitektur ist ein wichtiges Mittel, um die Kompliziertheit von Software einzudämmen. Developer, die auch mit komplizierten Systemen umzugehen vermögen, könnten einem solchen Architekturverständnis ablehnend gegenüberstehen.
URL dieses Artikels:
https://www.heise.de/-8971097
Links in diesem Artikel:
[1] mailto:sih@ix.de
Copyright © 2023 Heise Medien
(Bild: insta_photos/Shutterstock.com)
Meetings nerven! Also: abschaffen! Aber: Kommunikation ist wesentlicher Teil der Softwareentwicklung und Meetings ein wichtiges Kommunikationswerkzeug. Was nun?
Auslöser dieses Blog-Posts ist eine Twitter-Diskussion [1]. Dort ging es um die Idee, bei einem Video-Call im Hintergrund eine Anzeige zu installieren. Sie soll basierend auf dem Gehalt beziehungsweise dem Tagessatz der Beteiligten anzeigen, wie viel Geld der Video-Call kostet.
Vermutlich geht es bei der Anzeige aber nicht nur um die Kosten. Video-Calls nerven Technikerinnen und Techniker und halten sie von der wirklichen Arbeit ab. Es gibt nämlich eigentlich nur einen Indikator dafür, ob wir etwas erreicht haben: lauffähiger Code. Diesen zu entwickeln, erfordert Konzentration. Ein Video-Call kostet nicht nur Zeit, sondern unterbricht auch die Konzentration. Es dauert lange, bis man wieder produktiv am Code arbeiten kann. Die negativen Auswirkungen von Meetings auf die Produktion von lauffähigem Code sind also noch schlimmer, als es diese Anzeige nahelegen würde.
Tatsächlich hilft die Anzeige aber nicht weiter. Schlimmer: Der Idee liegt eine falsche Wahrnehmung über Softwareentwicklung zugrunde. Nicht Code zu produzieren, ist unser größtes Problem. Das größte Problem ist es, die gemeinsame Arbeit an der Software zu koordinieren und die Anforderungen zu verstehen. Ein großes Optimierungspotential ist, Features korrekt zu implementieren und die richtigen Features zu implementieren. Kleine Unterschiede können schon massive Auswirkungen haben. Ein krasses Beispiel: Ein einziges zusätzliches Eingabefeld kann 90 % des Umsatzes kosten [2]. Es ist also kontraproduktiv, dieses Eingabefeld umzusetzen – egal wie schnell oder effizient das passiert. Der lauffähige Code mag einem zwar das Gefühl geben, dass man etwas erreicht hat, aber in Wirklichkeit war es ein Schritt in die falsche Richtung. Die beste Option wäre gewesen, diesen Code gar nicht zu schreiben. Den Code möglichst schnell und effizient zu schreiben, ist eine Scheinoptimierung.
Um zu verstehen, was zu entwickeln ist, muss man wohl Meetings abhalten. Schriftliche Anforderungen können nicht alle Informationen transportieren. Rückfragen, das gemeinsame Entwickeln von Ideen, Hinterfragen – das alles verlangt direkte Kommunikation und Meetings. Aber die Meetings nerven ja dennoch, und das Problem muss irgendwie angegangen werden. Die Kosten des Meetings explizit zu machen, ist naheliegend, weil es relativ einfach ist. Es ist aber die falsche Optimierungsgröße. Meetings, bei denen relevante Informationen ausgetauscht oder wichtige Entscheidungen getroffen werden, sind nützlich und nerven daher vermutlich nicht. Leider ist Nützlichkeit nicht ganz so einfach messbar, wie die Kosten. Dieses Problem des Fokus auf Kosten, weil sie leichter messbar sind, haben auch anderen Bereichen der IT, wie in einem anderen Blog-Post [3] diskutiert. Gerade weil die gemeinsame Arbeit die große Herausforderung in der Softwareentwicklung ist, sind Optimierungen an der gemeinsamen Arbeite sehr sinnvoll.
Also sollten wir die Qualität von Meetings verbessern. Beispielsweise kann man nach jedem Meeting die Frage stellen, wie hilfreich die Teilnehmenden das Meeting fanden. Oder man kann ein Keep / Try Feedback zur Verbesserung einholen: Was sollten man beim nächsten Meeting beibehalten (Keep)? Was kann man ausprobieren (Try)? Auch alle Meetings firmenweit schlicht abzusagen, wie Shopify dies getan hat [4], hat den Vorteil, dass vermutlich nur die Meetings wieder aufgenommen werden, die wertvoll sind. Es geht jedoch vielleicht zu weit, weil gegebenenfalls wichtige Meetings auch abgesagt werden.
So oder so ist eine Bewertung und kontinuierliche Verbesserung von Meetings ein konstruktiver Weg, um den Wert der Meetings zu maximieren. Und daher sollten wir den Wert von Meetings maximieren - und nicht etwa die Anzahl oder die Kosten.
Das Problem der Softwareentwicklung ist die Koordination und die Arbeit an den richtigen Herausforderungen. Dafür sind Meetings notwendig. Also sollten wir Meetings nicht einfach abschaffen, sondern den Wert maximieren.
URL dieses Artikels:
https://www.heise.de/-7549813
Links in diesem Artikel:
[1] https://twitter.com/ewolff/status/1574378678796144640
[2] https://ai.stanford.edu/~ronnyk/2009controlledExperimentsOnTheWebSurvey.pdf
[3] https://www.heise.de/blog/IT-Projekte-Kostenfaktor-statt-Wettbewerbsvorteil-6007620.html
[4] https://www.heise.de/news/Schluss-mit-Gruppenmeetings-Shopify-holt-zum-Kalender-Kahlschlag-aus-7448427.html
[5] mailto:rme@ix.de
Copyright © 2023 Heise Medien
Die Frage "Ist diese Software-Architektur zukunftssicher?" kann man eigentlich generell mit "nein" beantworten. Schlimmer noch: Die Frage zu stellen, kann schon auf ein falsches Verständnis von Architektur hinweisen.
Die Frage "Ist diese Software-Architektur zukunftssicher?" kann man eigentlich generell mit "nein" beantworten. Schlimmer noch: Die Frage zu stellen, kann schon auf ein falsches Verständnis von Architektur hinweisen.
Die Softwarearchitektur eines IT-Systems umfasst zwei Bereiche: Die Technologien zur Umsetzung und die Strukturierung des Systems in einzelne Module. Geht es um die Zukunftssicherheit von Architekturen, muss man beide Bereiche betrachten.
Eine grobgranulare Struktur eines Systems ist notwendig, damit Menschen das System verstehen und ändern können. Softwaresysteme werden im Team entwickelt. Das führt zu einem Problem: Kein Mensch kann die Arbeit aller Menschen aus dem Team im Detail verstehen. Eine Strukturierung des Systems in Module ermöglicht ein Verständnis auf einer abstrakten Ebene - der Ebene der Module und nicht auf der Ebene einzelner Codezeilen.
Die architekturelle Struktur sollte die Module des Systems so anordnen, dass Funktionalitäten leicht zu ändern und zu verstehen sind. Also hängt die Struktur von den Funktionalitäten und damit von den Anforderungen ab. Das zentrale Problem bei der Softwareentwicklung ist, dass sich Anforderungen ändern – nicht nur weil Kunden neue Anforderungen stellen, sondern auch, weil beim Durchdenken oder bei der Anwendung des Systems Anforderungen klarer werden, sich neue Möglichkeiten offenbaren oder Inkonsistenzen auftauchen und beseitigt werden müssen. Teams, Kundinnen und Anwender lernen ständig mehr über das System und die zu entwickelnde Funktionalität. Dieses neue Wissen zu ignorieren,wäre absurd. Daher ergeben sich zwangsläufig Änderungen.
Einige Änderungen an den Anforderungen sind so signifikant, dass die Strukturierung des Systems und damit die Architektur angepasst werden muss. Ob das System zukunftssicher ist, entzieht sich also prinzipiell unserer Kenntnis, weil wir die Zukunft und die neuen Anforderungen nicht absehen können. Vielleicht passt die Architektur gut zu den neuen Anforderungen, vielleicht sind aber auch größere Änderungen notwendig.
Aber nicht alle neuen Anforderungen sind vollkommen überraschend. Natürlich ist es sinnvoll, absehbare Änderungen in den Entwurf der Architektur einzubeziehen. Wenn die Änderungen dann doch nicht erfolgen, ist die Architektur an einigen Stellen unnötig flexibel und daher möglicherweise an einigen Stellen zu kompliziert. Das ist aber ein weiterer Trade-off in der Architektur. Soll das System auf absehbare Änderungen vorbereitet werden oder nicht? Über solche Fragen nachzudenken und sie individuell zu entscheiden, ist sicher besser, als sie blind mit "You Ain't Gonna Need It" (YAGNI, Du wirst es nicht brauchen) zu beantworten. Dieses Motto stammt aus dem Extreme-Programming-Umfeld der Jahrtausendwende. Es diente dazu, sich gegen übermäßig generische Lösungen abzusetzen. Wenn man nämlich ein System so entwickelt, dass es auf alle denkbaren Änderungen vorbereitet ist, wird es übermäßig komplex. Daher sollte die Architektur nur absehbare Änderungen in Erwägung ziehen und diese auch nur dann in den Architektur einfließen lassen, wenn die Vorteile klar überwiegen.
Dennoch kann man in der Strukturierung eine gewissen Zukunftsfähigkeit des Systems erreichen. Wenn die Strukturierung das Verständnis nicht erleichtert oder wenn Module nicht lose gekoppelt sind und Änderungen dadurch immer größere Teile des System betreffen, dann ist das System schon jetzt nicht einfach wartbar. Das wird sich in Zukunft nicht verbessern.
Wenn zentrale Konzepte der Fachdomäne gar nicht im System abgebildet sind oder fachliche Konzepte generell im System schlecht repräsentiert sind, ist es schwierig die Abbildung der Fachlichkeit auf das System zu verstehen. Verständnis ist aber die Voraussetzung für jede Änderung.
Also kann man die Struktur des Systems möglichst eng an der Fachlichkeit ausrichten und so zukunftsfähig gestalten. Wenn die fachlichen Konzept klar und verständlich umgesetzt sind, kann man sie auch einfach ändern und auf zukünftige Anforderungen anpassen. Über die fachlichen Konzepte hinaus eingebaute Flexibilität schadet dabei mehr als sie hilft: Sie ist meistens an den falschen Stellen und verschlechtert damit die Verständlichkeit. Man kann eben zukünftige Änderungen nicht vorweg erahnen und einfach implementierbar machen.
Neben der Struktur ist auch die Technologieauswahl ein wichtiger Teil der Architektur. Softwareentwicklung unterliegt einem ständigen Technologiewandel. Man kann einem Technologie-Stack dennoch bescheinigen, dass er mehr oder weniger modern ist. Diese Aussage weist schon auf mangelnde Zukunftssicherheit hin: Was heute modern ist, ist morgen veraltet. “Modern” ist zunächst ein relativ inhaltsleerer Begriff: Was nützt es, wenn eine Technologie erst einige Jahre alt ist?
Die Modernität von Technologien darf kein Selbstzweck sein: Schließlich sollen Softwarearchitekturen Geschäftsprobleme lösen – und dazu ist ein möglichst moderner Technologie-Stack nicht zwingend notwendig. Aufwand, der in die Modernisierung von Technologien und das Erlernen neuer Ansätze fließt, sollte vielleicht besser in Aktivitäten fließen, die Geschäftswert erzeugen. Aber irgendwann sind Technologien so alt, dass sie nicht mehr weiter gepflegt werden. Spätestens wenn dann Sicherheitsupdates ausbleiben, muss man aktualisieren oder umsteigen. Sonst kann ein Sicherheitsproblem dazu führen, dass das System nicht mehr nutzbar ist oder gar erheblichen Schaden anrichtet. In beiden Fällen erzeugt das System keinen Geschäftswert mehr, sondern im Extremfall einen Geschäftsverlust. Wenn irgendwann die Technologien so alt sind, dass sich niemand mehr damit beschäftigen will, nimmt der Druck für eine Migration weiter zu.
Es kann natürlich Technologien geben, die scheinbar zukunftssicher sind. Die Programmiersprache Java beispielsweise gibt es seit über 25 Jahren. Aber auch hier gilt: Alte Java-Versionen bekommen keine Sicherheitsupdates mehr. Und Java-Code aus dem letzten Jahrhundert sieht wegen neuer Sprach-Features anders aus als aktueller Code. Schließlich gibt es ganz andere Frameworks oder zumindest neue Versionen der Frameworks. Selbst eine Technologie, die lange existiert, ist also einem Wandel unterworfen und muss ständig aktualisiert werden.
Anders gesagt: Man kommt nicht darum herum, neue Technologien einzusetzen. Der Wunsch nach einer Zukunftssicherheit ist nicht realisierbar.
Container können die Zukunftssicherheit erhöhen: Jeder Container enthält ein eigenes Dateisystem und ist von anderen Containern weitgehend isoliert. Aus Sicht der Software wirkt es fast so, als wäre jeder Container ein getrennter Computer mit einem eigenen Dateisystem, einer eigener Netzwerkschnittstelle usw. Daher können in jedem Container eine eigene Programmiersprache und eigene Frameworks eingesetzt werden. Wenn man beispielsweise mit Microservices die Teile des Systems auf mehrere Container verteilt, kann ein Update auf eine neue Technologie zunächst in einem Container und dann schrittweise in anderen Containern umgesetzt werden. Das ist risikoärmer und macht die Architektur zukunftssicherer, weil die Einführung neuer Technologien einfacher wird.
Container-Technologien sind aber auch irgendwann erfunden worden: Kubernetes gibt es seit 2014, Docker seit 2013. Bis die Technologien im Mainstream angekommen sind, hat es dann noch einige Jahre gedauert. Um sie zu nutzen, muss man ältere Projekte ändern. Diese Innovationen sind nicht vorhersehbar. 2012 kann kein Architektur-Review vorhergesehen haben, dass ein Projekt nicht zukunftssicher ist, weil es keine Container nutzt.
Und eines ist auch bei Containern sicher: Es wird eine Zeit geben, in der man die Nase rümpft, wenn jemand noch Container nutzt, weil es dann eine viel bessere, neue Technologie geben wird.
Hinzu kommt: In einem Frontend mehrere JavaScript-Frameworks gemeinsam zu nutzen bleibt eine echte Herausforderung – aber die Geschwindigkeit, mit der neue JavaScript-Frameworks erscheinen, ist nach wie vor beeindruckend. Also sind diese Probleme gerade da schwer lösbar, wo neue Technologien noch mit einer viel größeren Geschwindigkeit erscheinen.
Man sollte sich also an den Gedanken gewöhnen, dass man im Moment an Lösungen arbeitet, die irgendwann technologisch veraltet sind. Und man kann das Problem höchstens abmildern, aber nicht lösen.
Die Frage nach der Zukunftssicherheit kann sogar ein Hinweis auf ein Problem sein: Wenn eine Architektur zukunftssicher wäre, müsste man sie nicht korrigieren. Das ist aber wünschenswert. Wenn Korrekturen stattdessen als Schwäche einer Architektur interpretiert und daher möglichst wenige zum Ziel werden, kann ein Problem sein. Dann können Hinweise auf eigentlich notwendige Änderungen ignoriert werden, um keine Korrekturen an der Architektur vornehmen zu müssen. Wer will schon gerne eingestehen, dass die Architektur eben nicht zukunftssicher war? Durch das Unterdrücken der Änderungen erscheint die Architektur "zukunftssicher", aber in Wirklichkeit passt die Architektur zunehmend schlechter zum System. Dass Architekturen nicht rechtzeitig an Änderungen angepasst werden, ist vermutlich eine größere Quelle für schlechte Architekturen als Probleme mit dem ursprünglichen Entwurf. So führt der Wunsch nach einer zukunftssicheren Architektur zu einer schlechteren Architektur.
Aber diese Paradoxie muss nicht der einzige Grund für ausbleibende Änderungen an der Architektur sein. Eine Architektur zu ändern ist anstrengend: Schließlich hat man sich mit dem Entwurf viel Mühe gegeben und vielleicht wesentliche Konzepte sogar schon in Prototypen ausprobiert. Von diesen ganzen Mühen Abschied zu nehmen, kann schwer fallen, ist aber manchmal nötig. Und man sollte auch kein schlechtes Gewissen haben, weil die Architektur nun obsolet ist. Softwareentwicklung ist nur in Iterationen umsetzbar. Eine Iteration der Architektur trägt die nächste schon in sich. Dennoch muss man sich bei dem Entwurf der Architektur Mühe geben. Erst wenn man wirklich versucht, die Architektur zu entwerfen, werden sich die Optimierungspotentiale zeigen.
Wenn es notwendig ist, Architekturen ändern zu können, kann die Erstellung der Architektur keine Phase in einem Projekt sein, die irgendwann abgeschlossen ist. Schließlich muss die Architektur ständig an die sich ändernde Welt angepasst werden. Dazu sollte es einen Prozess geben. Wenn es nämlich keinen Prozess für Änderungen an der Architektur gibt, wird sie vermutlich nicht angepasst werden. Dann lassen sich die Funktionalitäten zunehmend schlechter umsetzen.
Die Frage nach einem Architekturänderungsprozess ist also wichtiger als die Frage nach der Zukunftssicherheit der Architektur. Und Projekte, die auf diese Frage keine Antwort haben, setzen sich der Gefahr aus, in Zukunft Schwierigkeiten mit der Architektur zu haben.
Technologische Innovationen und neue Anforderungen machen Änderungen an der Architektur zwingend - sie kann nicht zukunftssicher sein. Lösung: Dieser Realität in die Augen sehen und Architekturen anpassen, wenn notwendig.
Vielen Dank an Gerrit Beine, Martin Eigenbrodt, Joachim Praetorius und Gernot Starke für die Kommentare zu einer früheren Version des Artikels.
URL dieses Artikels:
https://www.heise.de/-6655162
Links in diesem Artikel:
[1] mailto:eberhard.wolff@gmail.com
Copyright © 2022 Heise Medien
Die Frage "Ist diese Software-Architektur zukunftssicher?" kann man eigentlich generell mit "nein" beantworten. Schlimmer noch: Die Frage zu stellen, kann schon auf ein falsches Verständnis von Architektur hinweisen.
Die Softwarearchitektur eines IT-Systems umfasst zwei Bereiche: Die Technologien zur Umsetzung und die Strukturierung des Systems in einzelne Module. Geht es um die Zukunftssicherheit von Architekturen, muss man beide Bereiche betrachten.
Eine grobgranulare Struktur eines Systems ist notwendig, damit Menschen das System verstehen und ändern können. Softwaresysteme werden im Team entwickelt. Das führt zu einem Problem: Kein Mensch kann die Arbeit aller Menschen aus dem Team im Detail verstehen. Eine Strukturierung des Systems in Module ermöglicht ein Verständnis auf einer abstrakten Ebene - der Ebene der Module und nicht auf der Ebene einzelner Codezeilen.
Die architekturelle Struktur sollte die Module des Systems so anordnen, dass Funktionalitäten leicht zu ändern und zu verstehen sind. Also hängt die Struktur von den Funktionalitäten und damit von den Anforderungen ab. Das zentrale Problem bei der Softwareentwicklung ist, dass sich Anforderungen ändern – nicht nur weil Kunden neue Anforderungen stellen, sondern auch, weil beim Durchdenken oder bei der Anwendung des Systems Anforderungen klarer werden, sich neue Möglichkeiten offenbaren oder Inkonsistenzen auftauchen und beseitigt werden müssen. Teams, Kundinnen und Anwender lernen ständig mehr über das System und die zu entwickelnde Funktionalität. Dieses neue Wissen zu ignorieren,wäre absurd. Daher ergeben sich zwangsläufig Änderungen.
Einige Änderungen an den Anforderungen sind so signifikant, dass die Strukturierung des Systems und damit die Architektur angepasst werden muss. Ob das System zukunftssicher ist, entzieht sich also prinzipiell unserer Kenntnis, weil wir die Zukunft und die neuen Anforderungen nicht absehen können. Vielleicht passt die Architektur gut zu den neuen Anforderungen, vielleicht sind aber auch größere Änderungen notwendig.
Aber nicht alle neuen Anforderungen sind vollkommen überraschend. Natürlich ist es sinnvoll, absehbare Änderungen in den Entwurf der Architektur einzubeziehen. Wenn die Änderungen dann doch nicht erfolgen, ist die Architektur an einigen Stellen unnötig flexibel und daher möglicherweise an einigen Stellen zu kompliziert. Das ist aber ein weiterer Trade-off in der Architektur. Soll das System auf absehbare Änderungen vorbereitet werden oder nicht? Über solche Fragen nachzudenken und sie individuell zu entscheiden, ist sicher besser, als sie blind mit "You Ain't Gonna Need It" (YAGNI, Du wirst es nicht brauchen) zu beantworten. Dieses Motto stammt aus dem Extreme-Programming-Umfeld der Jahrtausendwende. Es diente dazu, sich gegen übermäßig generische Lösungen abzusetzen. Wenn man nämlich ein System so entwickelt, dass es auf alle denkbaren Änderungen vorbereitet ist, wird es übermäßig komplex. Daher sollte die Architektur nur absehbare Änderungen in Erwägung ziehen und diese auch nur dann in den Architektur einfließen lassen, wenn die Vorteile klar überwiegen.
Dennoch kann man in der Strukturierung eine gewissen Zukunftsfähigkeit des Systems erreichen. Wenn die Strukturierung das Verständnis nicht erleichtert oder wenn Module nicht lose gekoppelt sind und Änderungen dadurch immer größere Teile des System betreffen, dann ist das System schon jetzt nicht einfach wartbar. Das wird sich in Zukunft nicht verbessern.
Wenn zentrale Konzepte der Fachdomäne gar nicht im System abgebildet sind oder fachliche Konzepte generell im System schlecht repräsentiert sind, ist es schwierig die Abbildung der Fachlichkeit auf das System zu verstehen. Verständnis ist aber die Voraussetzung für jede Änderung.
Also kann man die Struktur des Systems möglichst eng an der Fachlichkeit ausrichten und so zukunftsfähig gestalten. Wenn die fachlichen Konzept klar und verständlich umgesetzt sind, kann man sie auch einfach ändern und auf zukünftige Anforderungen anpassen. Über die fachlichen Konzepte hinaus eingebaute Flexibilität schadet dabei mehr als sie hilft: Sie ist meistens an den falschen Stellen und verschlechtert damit die Verständlichkeit. Man kann eben zukünftige Änderungen nicht vorweg erahnen und einfach implementierbar machen.
Neben der Struktur ist auch die Technologieauswahl ein wichtiger Teil der Architektur. Softwareentwicklung unterliegt einem ständigen Technologiewandel. Man kann einem Technologie-Stack dennoch bescheinigen, dass er mehr oder weniger modern ist. Diese Aussage weist schon auf mangelnde Zukunftssicherheit hin: Was heute modern ist, ist morgen veraltet. “Modern” ist zunächst ein relativ inhaltsleerer Begriff: Was nützt es, wenn eine Technologie erst einige Jahre alt ist?
Die Modernität von Technologien darf kein Selbstzweck sein: Schließlich sollen Softwarearchitekturen Geschäftsprobleme lösen – und dazu ist ein möglichst moderner Technologie-Stack nicht zwingend notwendig. Aufwand, der in die Modernisierung von Technologien und das Erlernen neuer Ansätze fließt, sollte vielleicht besser in Aktivitäten fließen, die Geschäftswert erzeugen. Aber irgendwann sind Technologien so alt, dass sie nicht mehr weiter gepflegt werden. Spätestens wenn dann Sicherheitsupdates ausbleiben, muss man aktualisieren oder umsteigen. Sonst kann ein Sicherheitsproblem dazu führen, dass das System nicht mehr nutzbar ist oder gar erheblichen Schaden anrichtet. In beiden Fällen erzeugt das System keinen Geschäftswert mehr, sondern im Extremfall einen Geschäftsverlust. Wenn irgendwann die Technologien so alt sind, dass sich niemand mehr damit beschäftigen will, nimmt der Druck für eine Migration weiter zu.
Es kann natürlich Technologien geben, die scheinbar zukunftssicher sind. Die Programmiersprache Java beispielsweise gibt es seit über 25 Jahren. Aber auch hier gilt: Alte Java-Versionen bekommen keine Sicherheitsupdates mehr. Und Java-Code aus dem letzten Jahrhundert sieht wegen neuer Sprach-Features anders aus als aktueller Code. Schließlich gibt es ganz andere Frameworks oder zumindest neue Versionen der Frameworks. Selbst eine Technologie, die lange existiert, ist also einem Wandel unterworfen und muss ständig aktualisiert werden.
Anders gesagt: Man kommt nicht darum herum, neue Technologien einzusetzen. Der Wunsch nach einer Zukunftssicherheit ist nicht realisierbar.
Container können die Zukunftssicherheit erhöhen: Jeder Container enthält ein eigenes Dateisystem und ist von anderen Containern weitgehend isoliert. Aus Sicht der Software wirkt es fast so, als wäre jeder Container ein getrennter Computer mit einem eigenen Dateisystem, einer eigener Netzwerkschnittstelle usw. Daher können in jedem Container eine eigene Programmiersprache und eigene Frameworks eingesetzt werden. Wenn man beispielsweise mit Microservices die Teile des Systems auf mehrere Container verteilt, kann ein Update auf eine neue Technologie zunächst in einem Container und dann schrittweise in anderen Containern umgesetzt werden. Das ist risikoärmer und macht die Architektur zukunftssicherer, weil die Einführung neuer Technologien einfacher wird.
Container-Technologien sind aber auch irgendwann erfunden worden: Kubernetes gibt es seit 2014, Docker seit 2013. Bis die Technologien im Mainstream angekommen sind, hat es dann noch einige Jahre gedauert. Um sie zu nutzen, muss man ältere Projekte ändern. Diese Innovationen sind nicht vorhersehbar. 2012 kann kein Architektur-Review vorhergesehen haben, dass ein Projekt nicht zukunftssicher ist, weil es keine Container nutzt.
Und eines ist auch bei Containern sicher: Es wird eine Zeit geben, in der man die Nase rümpft, wenn jemand noch Container nutzt, weil es dann eine viel bessere, neue Technologie geben wird.
Hinzu kommt: In einem Frontend mehrere JavaScript-Frameworks gemeinsam zu nutzen bleibt eine echte Herausforderung – aber die Geschwindigkeit, mit der neue JavaScript-Frameworks erscheinen, ist nach wie vor beeindruckend. Also sind diese Probleme gerade da schwer lösbar, wo neue Technologien noch mit einer viel größeren Geschwindigkeit erscheinen.
Man sollte sich also an den Gedanken gewöhnen, dass man im Moment an Lösungen arbeitet, die irgendwann technologisch veraltet sind. Und man kann das Problem höchstens abmildern, aber nicht lösen.
Die Frage nach der Zukunftssicherheit kann sogar ein Hinweis auf ein Problem sein: Wenn eine Architektur zukunftssicher wäre, müsste man sie nicht korrigieren. Das ist aber wünschenswert. Wenn Korrekturen stattdessen als Schwäche einer Architektur interpretiert und daher möglichst wenige zum Ziel werden, kann ein Problem sein. Dann können Hinweise auf eigentlich notwendige Änderungen ignoriert werden, um keine Korrekturen an der Architektur vornehmen zu müssen. Wer will schon gerne eingestehen, dass die Architektur eben nicht zukunftssicher war? Durch das Unterdrücken der Änderungen erscheint die Architektur "zukunftssicher", aber in Wirklichkeit passt die Architektur zunehmend schlechter zum System. Dass Architekturen nicht rechtzeitig an Änderungen angepasst werden, ist vermutlich eine größere Quelle für schlechte Architekturen als Probleme mit dem ursprünglichen Entwurf. So führt der Wunsch nach einer zukunftssicheren Architektur zu einer schlechteren Architektur.
Aber diese Paradoxie muss nicht der einzige Grund für ausbleibende Änderungen an der Architektur sein. Eine Architektur zu ändern ist anstrengend: Schließlich hat man sich mit dem Entwurf viel Mühe gegeben und vielleicht wesentliche Konzepte sogar schon in Prototypen ausprobiert. Von diesen ganzen Mühen Abschied zu nehmen, kann schwer fallen, ist aber manchmal nötig. Und man sollte auch kein schlechtes Gewissen haben, weil die Architektur nun obsolet ist. Softwareentwicklung ist nur in Iterationen umsetzbar. Eine Iteration der Architektur trägt die nächste schon in sich. Dennoch muss man sich bei dem Entwurf der Architektur Mühe geben. Erst wenn man wirklich versucht, die Architektur zu entwerfen, werden sich die Optimierungspotentiale zeigen.
Wenn es notwendig ist, Architekturen ändern zu können, kann die Erstellung der Architektur keine Phase in einem Projekt sein, die irgendwann abgeschlossen ist. Schließlich muss die Architektur ständig an die sich ändernde Welt angepasst werden. Dazu sollte es einen Prozess geben. Wenn es nämlich keinen Prozess für Änderungen an der Architektur gibt, wird sie vermutlich nicht angepasst werden. Dann lassen sich die Funktionalitäten zunehmend schlechter umsetzen.
Die Frage nach einem Architekturänderungsprozess ist also wichtiger als die Frage nach der Zukunftssicherheit der Architektur. Und Projekte, die auf diese Frage keine Antwort haben, setzen sich der Gefahr aus, in Zukunft Schwierigkeiten mit der Architektur zu haben.
Technologische Innovationen und neue Anforderungen machen Änderungen an der Architektur zwingend - sie kann nicht zukunftssicher sein. Lösung: Dieser Realität in die Augen sehen und Architekturen anpassen, wenn notwendig.
Vielen Dank an Gerrit Beine, Martin Eigenbrodt, Joachim Praetorius und Gernot Starke für die Kommentare zu einer früheren Version des Artikels.
URL dieses Artikels:https://www.heise.de/-6655162
Copyright © 2022 Heise Medien
Software-Entwicklung ist voller spannender Herausforderungen, und es gibt immer etwas Neues zu lernen: Software ist schließlich eine der komplexesten Dinge, die von Menschen gebaut wird. Aber die Ergebnisse in der Realität sind manchmal mehr als enttäuschend – sie sind beschämend.
In der aktuellen c't ist ein Artikel [1], dessen Untertitel eigentlich schon der erste Aufreger sein könnte: Es geht um "typische" Datenlecks in Software für die Test- und Impfterminvergabe. Mit anderen Worten: Software in diesem Bereich ist so unsicher, dass es typische Fehler gibt – und diese Software ist auch in Produktion. Die im Artikel diskutierte Software ist medizinische Software. Nehmen wir an, wir würden über andere Medikamente sprechen. Wäre es akzeptabel, dass es "typische" vermeidbare Sicherheitsprobleme bei Medikamenten gäbe, die auch tatsächlich verordnet und eingenommen werden?
Im Übrigen ist die c’t in diesem Bereich nicht alleine. Die Gruppe zerforschung beschäftigt sich auch intensiv mit der Sicherheit solcher Lösungen und schreibt [2]: “Wir haben mittlerweile das vierte Testzentrums-Datenleck in drei Monaten gefunden und sind einfach nur noch genervt.” Was würden wir sagen, wenn es das vierte Problem in drei Monaten mit verschiedenen Medikamenten gäbe? Und Experten anschließend von der Sicherheit der Medikamente “einfach nur noch genervt” sind?
Der Vergleich zwischen Software und Medikamenten scheint auf den ersten Blick weit hergeholt zu sein. Mittlerweile ist es vielen gleichgültig, wo überall Daten leaken. Es passiert einfach so häufig, und bestimmte Unternehmen leben von dem Ausspionieren ihrer Kunden. Aber eine Schnelltest-Software [3]machte es sehr einfach Testergebnisse zu fälschen. Solche Testergebnisse werden verlangt, um Personen vor einer Ansteckung durch Kontakt mit Infizierten zu schützen. Wenn die Testergebnisse gefälscht werden können, stellt das ein Gesundheitsrisiko dar – wie ein fehlerhaftes Medikament auch. Die Luca App zur Kontaktverfolgung konnte sogar zu Angriffen auf Gesundheitsämter [4] genutzt werden. Über die Konsequenzen eines erfolgreichen Angriffs will ich nicht spekulieren.
Die Einleitung des sehr lesenswerten c’t Artikels berichtet dann, dass bei der c't eine Vielzahl von Meldungen über Datenlecks bei Software für Test- und Impfterminvergabe eingegangen ist. Die c't verfolgt die Probleme und informiert die Hersteller. Hier ist der nächste Aufreger: Die c't, zerforschung und viele andere machen sicher einen super Job – aber offensichtlich muss eine Zeitschrift oder eine Gruppe von Expert:innen sich dieser Probleme annehmen. Nehmen wir als Analogie wieder Medikamente. Wäre es akzeptabel, wenn eine Zeitschrift routinemäßig über mögliche Probleme mit Medikamenten informieren würde, und diese Zeitschrift dann anschließend die Fälle näher untersucht und den Herstellern mit Rat und Tat zur Seite steht – und nur so die Probleme wirklich behoben werden? Sicher gibt es vereinzelt Medikamenten-Skandale, die über die Presse bekannt werden, und Fachzeitschrift, die wissenschaftliche Studien über Medikamente verbreiten. Aber eklatante Probleme mit Medikamenten sind eben nicht Routine. Und in der Branche und bei den Behörden sind Maßnahmen etabliert, damit das so bleibt.
Das Fazit ist dann der nächste Aufreger: "Ärzte und Apotheker sollten sich die Software sehr gewissenhaft ansehen (oder einen unabhängigen IT-Experten zu Rate ziehen)." Man kann kaum ernsthaft von Ärzt:innen und Apotheker:innen die Kompetenz verlangen, die Sicherheit einer Software zu bewerten. Ich arbeite im Bereich Software-Entwicklung und würde mir das selber nicht wirklich zutrauen. Vor kurzem bin ich privat um Rat in Bezug auf ein Sicherheitsthema gebeten worden und habe auch einen Rat gegeben. Allerdings bleibt das schlechte Gefühl, dass ich gegebenenfalls ein Detail übersehen habe, das am Ende dann doch große Auswirkungen hat. Daher ist der Hinweis, Expert:innen zu Rate zu ziehen, auch sehr sinnvoll. Aber auch hier bemühe ich den Vergleich zu einem Medikament: Kann man von einem Patienten verlangen, sich selber mit der Sicherheit eines Medikaments zu beschäftigen? Ich erwarte eigentlich, dass Medikamente, die ich in der Apotheke kaufe oder die mir ein Arzt verordnet, sicher sind. Üblicherweise werde ich sogar von Apotheker:innen und Ärzt:innen über die Details und mögliche Probleme proaktiv beraten.
Die Verantwortung für den Datenschutz auf die Nutzer:innen zu verlagern, kann desaströse Konsequenzen haben. Einige Lehrer:innen, die auf Eigeninitiative Videokonferenz-Lösungen in der Pandemie für ihren Unterricht genutzt haben, mussten die Sicherheit und den Datenschutz dieser Lösungen selber bewerten, weil sie oft dazu keine klaren Produktempfehlungen bekommen haben. Am Ende müssen die Lehrer:innen mit den Konsequenzen leben, wenn ihre Beurteilung falsch war – oder sie unterlassen es, sich dem Risiko auszusetzen und machen eben keinen Unterricht per Videokonferenz. Beide Konsequenzen sind nicht akzeptabel.
Aber die Empfehlung, sich die Lösungen anzuschauen, ist skurrilerweise sinnvoll: Tatsächlich können c't -Leser:innen meiner Einschätzung nach die geschilderten Herausforderungen nachvollziehen und auch Software auf diese Schwächen untersuchen. Dann sind diese Probleme aber auch für Software-Entwickler:innen nachvollziehbar – und das wirft die Frage auf, warum sie in Software überhaupt vorhanden sind. Mit anderen Worten: Wir sprechen nicht über subtile Herausforderungen, sondern solche, die man nach dem Studium einiger Seiten einer Zeitschrift verstehen kann und vermutlich auch abstellen können müsste – und daran scheitern die Hersteller dieser Software-Lösungen.
Es ist gut, dass die c’t und viele Sicherheitsforscher:innen und Expert:innen sich kümmern. Aber es ist erschreckend, dass unsere Branche der Softwareentwicklung solche fehlerhaften Produkte auf den Markt bringt. Als Ergebnis gibt es keinen Aufschrei, sondern eben einen Artikel, der davon handelt, wie Nutzer:innen sich mit der Situation arrangieren können und wie sie selber herausfinden können, ob die Software ausreichend sicher ist. Sind wir so abgestumpft, dass wir diesen Zustand akzeptieren? Ist unsere Branche wirklich so unprofessionell, dass sich Nutzer:innen eben mit diesen Mängeln unserer Produkte arrangieren müssen? Ist es unser Qualitätsanspruch, das unserer Produkte Fehler haben, die man als interessierter Laie nach dem Lesen einiger Seiten in einer Zeitschrift diagnostizieren kann?
Besonders bedenklich ist, dass diese Anwendungen personenbezogene Gesundheitsdaten verwalten. Diese Daten sind sehr sensibel und besonders schützenswert. Auch die Luca App [5] zur Kontaktverfolgung geht mit Gesundheitsdaten um, weil über die App ja gerade infizierte Personen verfolgt werden soll. Dazu muss der Infektionsstatus bekannt sein – und das sind Gesundheitsdaten. Auch für diese App gibt es sehr viel Kritik und Sicherheitslücken [6] bis hin zu den schon erwähnten möglichen Angriffen auf Gesundheitsämter. Dazu hat der Sicherheitsexperten Marcus Mengs zunächst ein Dokument mit fast 21.000 Wörtern geschrieben und dann die Arbeit an der Luca App eingestellt. Der Grund steht im Dokument [7]: “Der Hersteller gibt mir keine Zeit die Zusammenhänge zu dokumentieren, welche zu Sicherheitslücken im Code führen und patcht stattdessen ständig Code mit neuen Fehlern nach.”
Mit mindestens 25 Mio € Einnahmen [8] muss man die Luca App einen kommerziellen Erfolg nennen. Und die App hat bekanntermaßen prominente Unterstützung durch den Musiker Smudo [9]. Seine Band “Die fantastischen Vier” ist “begeistert” von dem Produkt und sieht sich als Teil des Teams [10]. Das zeigt eine Erklärungsmöglichkeit für den Zustand unserer Branche: Wenn der Applaus der Prominenz und der kommerzielle Erfolg von der Sicherheit der Anwendungen entkoppelt ist, dann ist es unlogisch, sich mit Sicherheit zu beschäftigen, weil sie für den Erfolg egal ist – außer man hat ethische Prinzipien, die dem Ignorieren entgegenstehen.
Die Spitze der Absurdität ist aber das immer wieder zu hörende Argument, dass der Datenschutz einer effektiven und effizienten IT im Wege steht. Der "Datenschutz", der in dem c’t-Artikel beschrieben wird oder der bei der Luca App “umgesetzt” wurde, kann damit zumindest nicht gemeint sein. So ist der Datenschutz auf der einen Seite nicht gewährleistet, kann aber gleichzeitig als Entschuldigung für weitere Mängel unserer Branche dienen.
Aber es gibt auch Lichtblicke. Ich war an Softwareprojekten beteiligt, die unter anderem auch personenbezogene Gesundheitsdaten verwaltet haben. Dort war sehr präsent, dass diese Daten besonders geschützt werden müssen und dementsprechend wurden diese Herausforderungen adressiert. Auch in vielen anderen Kontexten habe ich beispielsweise die Anforderungen durch die Datenschutzgrundverordnung DSGVO als wesentlich für Architektur-Diskussionen erlebt. Und natürlich gibt es für die Kontaktverfolgung-Anwendungen wie die Corona-Warn-App, die so konsequent auf Datenschutz ausgerichtet ist, dass sogar der Chaos Computer Club sie lobt [11]. Und den bereits erwähnten Sicherheitsexpert:innen und vielen anderen, die hier gar nicht erwähnt werden, ist die Situation offensichtlich nicht egal, sondern sie arbeiten aktiv daran sie zu verbessern - wofür ich mich an dieser Stelle bedanken möchte.
Am Ende bleibt aber die unangenehme Frage, ob unsere Branche im Vergleich zu anderen Branchen verantwortungsloser handelt. So oder so sollten wir uns alle anstrengen, in Zukunft Sicherheitsprobleme in Software zu vermeiden. Das ist besser, als sich zu schämen. Und das Studium des Artikels in der c't oder die Werke der Sicherheitsexpert:innen kann ein guter erster Schritt sein, um Sicherheitslücken kennenzulernen und zukünftig zu vermeiden. Vielleicht wird unsere Branche dann endlich erwachsener und verantwortungsvoller.
Leider ist die Qualität von Software-Lösungen oft mehr als schlecht. Sich dafür zu schämen ist aber nicht so effektiv, wie die Situation zu verbessern.
Vielen Dank an Anja Kammer, Tammo van Lessen, Tanja Maritzen, Joachim Praetorius, Max Schröter, Stefan Tilkov und Jan Seeger für die Kommentare zu einer früheren Version des Artikels.
URL dieses Artikels:https://www.heise.de/-6116235
Links in diesem Artikel:[1] https://www.heise.de/select/ct/2021/14/2113009092122225886[2] https://zerforschung.org/posts/medicant/[3] https://zerforschung.org/posts/medicus/[4] https://de.wikipedia.org/wiki/Luca_(App)#Angriff_auf_Gesundheits%C3%A4mter_und_Datenklau_durch_Code-Injection[5] https://www.heise.de/thema/Luca_App[6] https://de.wikipedia.org/wiki/Luca_(App)#Kritik[7] https://github.com/mame82/LucaAppIssues/blob/main/abandoned_issues.md[8] https://de.wikipedia.org/wiki/Luca_(App)#Einkauf_der_App_trotz_schwerer_M%C3%A4ngel,_ohne_staatliche_Ausschreibung[9] https://de.wikipedia.org/wiki/Luca_(App)#Entwicklung[10] https://www.luca-app.de/uber-uns/[11] https://www.zdf.de/nachrichten/politik/corona-app-launch-100.html
Copyright © 2021 Heise Medien
Lange genug hat es geheißen, dass IT-Projekte einen Wettbewerbsvorteil versprechen. Schaut man der Realität ins Auge, wird ein IT-Projekt jedoch wie ein Kostenfaktor behandelt – nicht anders als Strom oder Miete. Dabei könnte es anders sein.
Wohl alle in der IT denken, dass eine effiziente IT einen Wettbewerbsvorteil verschaffe. Daten sind bekanntermaßen das neue Öl. Digitalisierung macht alles zu Software, und wer Software beherrscht, beherrscht den Markt. IT-Projekte sind offensichtlich notwendig, um diese Vorteile tatsächlich zu realisieren.
Schauen wir uns ein typisches IT-Projekt an. Die Kosten sind praktisch immer bekannt. Die laufenden Personalkosten lassen sich relativ einfach ermitteln, die Projektlaufzeit ist ebenfalls bekannt und auch Faktoren wie Hardwarekosten werden meistens sehr genau ermittelt. Zeiten und Termine werden geschätzt, Budgets festgelegt, und wenn sie überschritten werden, wird das natürlich gemanagt. Und deutliche Überschreitungen haben ernsthafte Konsequenzen.
Wenn die IT-Projekte einen Wettbewerbsvorteil erzeugen sollen, dann müssen die Business-Ziele ebenfalls gemanagt werden – sei es das Erschließen neuer Märkte oder das Optimieren bekannter Prozesse. Die Ziele müssen eigentlich sogar im Mittelpunkt stehen. Natürlich basieren Projekte oft auf einem Business Case, der beispielsweise in einer Präsentation festgehalten worden ist und dazu dient, ein Projekt zu rechtfertigen und zu starten. Aber das bedeutet noch lange nicht, dass die Ziele tatsächlich das Geschehen in den laufenden Projekten bestimmen.
In den verschiedenen Projekten, die man als Berater sieht, sind den Teams die Business-Ziele der Projekte nicht immer klar. In einigen Projekten gibt es beispielsweise Ziele wie einen Nutzen für Endkunden, aber sie sind dem Team nicht kommuniziert oder bestimmen nicht die tägliche Arbeit. Bei anderen Projekten bleiben die Ziele dauerhaft unklar.
Werkzeuge wie Burn-Down-Charts, die den noch verbliebenen Aufwand und damit letztlich die verbliebene Zeit und das verbleibende Budget zeigen und an alle klar kommunizieren, sind hingegen üblich. Wie gesagt: Kosten und Budgets werden eigentlich immer gemanagt. Interessanterweise ist ein Burn-Down-Chart gerade bei agilen Projekten üblich, die eigentlich versprechen, Business-Ziele besser zu erreichen.
Ein Beispiel für die Vernachlässigung von Business-Zielen können Projekte für die Migration auf eine neue Technologie sein. An den Funktionalitäten ändert sich nichts. So wird zwar ein Business-Ziel wie niedrigere Betriebskosten oder ein langfristig stabiler Betrieb ermöglicht, aber solche Projekte könnten oft zusätzlich andere Business-Ziele durch Änderungen an der Logik recht einfach umsetzen. Schließlich wird das System ja sowieso komplett umgestellt. Man kann diese Chance nutzen, um das System zu verbessern und so mehr Business-Werte zu schaffen. Das Projekt kann dadurch aber auch zu komplex und risikoreich werden. Eine solche Abwägung zwischen zusätzlichem Business-Wert und Risiko erfolgt oft aber nicht – die Kosten hingegen werden auch bei diesen Projekten überwacht.
Wenn man IT als Wettbewerbsvorteil leben will, muss man nicht nur die Business-Ziele kennen, sondern den Business Case als Geldbetrag schätzen. Wer beispielsweise durch ein Projekt mehr Umsatz oder Gewinn erwartet, kann ausrechnen, wie viel Geld das wert ist. Der Wert eines Unternehmens wird auch anhand finanzieller Kenngrößen ermittelt – warum also bei einem Projekt nicht genauso vorgehen?
Nun kann man argumentieren, dass der Business-Wert eines Projekts viel schwieriger zu ermitteln ist als das verbrauchte und das übrige Budget. Aber der Aufwand für ein Softwareprojekt ist ebenfalls schwierig zu schätzen. Eigentlich ist das sogar unmöglich, weil Softwareprojekte so komplex sind, dass sie sich einer detaillierten Planung entziehen. Deswegen nutzt man iterativ-inkrementelle Methoden, die in einzelnen kleinen Inkrementen vorgehen, die wegen der geringeren Größe einfacher abzuschätzen sind. Softwareentwicklungsteams müssen sich also darin bewähren, trotz widriger Umstände Aufwände und Budgets abzuschätzen. Ist es tatsächlich schwieriger, den Business-Wert der Projekte abzuschätzen? Zumindest probieren könnte man es, aber selbst ein solcher Versuch bleibt meistens aus. Strukturierte Ansätze, solche Werte zu ermitteln, existieren – man muss sie nur anwenden.
Außerdem kann man gerade beim Business-Wert große Überraschungen erleben: Ein Produkt, dass keine Kunden findet, ist wertlos. Daher ist es eigentlich noch wichtiger, den Business-Wert zu ermitteln und als das Budget nachzuhalten. Denn wenn man Geld für etwas Wertloses ausgibt, ist das schlicht unsinnig. Wenn man hingegen die Chance verpasst, Projekte, die bei Kunden sehr beliebt und daher wertvoll sind, besser zu unterstützen, ist das ebenso schlecht.
Der Wert eines Projekts kann dabei erheblich sein. Mir ist ein Projekt in Erinnerung, das sich bereits vor dem Start amortisiert hatte, weil der Auftraggeber in Erwartung der neuen Software andere Finanzgeschäfte abschließen konnte und dadurch das Projekt-Budget erwirtschaften konnte. Und weil Software immer wichtiger wird, steigt auch der Wert guter Software.
Hätte man eine solche finanzielle Bewertung, würden sich die Bedingungen in den Projekten ändern. Statt die Frage zu stellen, wo man Aufwand sparen kann, wird die Frage, wo man mehr Werte schaffen kann, plötzlich genauso wichtig. Es geht nicht nur um Budgetüberschreitungen, sondern auch um die geschaffenen Werte. Ohne eine solche finanzielle Kenngröße für den Business-Wert liegt es nahe, die Projekte nach den Kosten zu beurteilen und zu optimieren, weil es die einzige finanziellen Kenngrößen sind, die eigentlich immer bekannt sind.
Neben dem Business-Wert eines Projekts gibt es eine weitere Kenngröße, die angeblich wichtig für IT ist: Durchlaufzeit, bis ein Feature tatsächlich in Produktion ist. Aber auch hier ist stellt sich die Frage, ob diese Größe wirklich aktiv gemanagt wird. Projekte wissen sicherlich, wie schnell sie eine Änderung in Produktion bringen können. Ob sie diese Zahl reporten und danach gemessen werden, ist eine ganz andere Frage. Außerdem gilt auch hier: Einen Wert sollte man als Geldbetrag ausdrücken können. Dazu bietet sich eine Größe an: Wie viele Kosten entstehen, wenn ein Feature sich verzögert? Man spricht vom "Cost of Delay".
Im "State of DevOps 2018 [1]"-Report gibt es dazu eine interessante Grafik von Maersk (Seite 46). Sie zeigt, dass es drei Features gibt, deren Verzögerung um eine Woche 7 Millionen US-Dollar kosten würde – vermutlich, weil Kunden abspringen oder Prozesse nicht rechtzeitig optimiert werden können. Solche Grafiken oder Aufstellungen haben in Projekten Seltenheitswert. Mit anderen Worten: Durchlaufzeit ist so unwichtig, dass man sich noch nicht einmal die Mühe macht, den möglichen Vorteil überhaupt finanziell zu bewerten.
Es ist also üblich, die Kosten eines Projekts finanziell zu bewerten und im Auge zu behalten. Business-Ziele sind oft schlecht kommuniziert. Und es ist sehr ungewöhnlich, den Business-Wert eines Projekts tatsächlich als Geldbetrag auszudrücken. So verschiebt sich der Fokus von dem Schaffen von Werten auf die Optimierung der Kosten, die als einzige Größe wirklich bekannt sind. IT wird dann unfreiwillig und ungeplant zu einem Kosten- statt zu einem Wettbewerbsfaktor. Das muss natürlich nicht so sein: Dazu müssen aber Business-Ziele, der Business-Wert, der Business Case und damit die erzeugten Werte bekanntund idealerweise als finanzielle Kenngrößen etabliert sein.
Die Kosten von IT-Projekten werden typischerweise gemanagt, aber der potenziell geschaffene Wert noch nicht einmal als Geldbetrag ermittelt. So wird die IT zu einem reinen Kostenfaktor.
Vielen Dank an meine Kolleg:innen Gerrit Beine, Matthias Déjà, Anja Kammer und Stefan Tilkov für die Kommentare zu einer früheren Version des Artikels.
URL dieses Artikels:https://www.heise.de/-6007620
Links in diesem Artikel:[1] https://services.google.com/fh/files/misc/state-of-devops-2018.pdf
Copyright © 2021 Heise Medien
Das Wasserfall-Modell ist recht alt, aber taucht dennoch bei der Diskussion über Softwareentwicklungsprozesse immer noch sehr häufig auf. Die Geschichte dieses Modells ist weitgehend unbekannt – dabei zeigt sie die Herausforderungen des Modells und warum man es nicht nutzen sollte.
Das einfache Wasserfall-Modell beschreibt ein Prozessmodell für die Softwareentwicklung. Es hat folgende Eigenschaften:
Die Visualisierung ist dementsprechend ein Wasserfall, bei dem die Phasen von oben links nach unten rechts angeordnet sind. Das "Wasser" entspricht jeweils den Ergebnisdokumenten, die dann in die Folgephase einfließen. Die einzelnen Phasen können sich dabei in jedem Projekt unterscheiden.
Vorbedingung für dieses Modell ist, dass die Anforderungen sich nicht wesentlich ändern. Sonst geht schon das Ergebnis der ersten Phase von falschen Voraussetzungen aus und damit auch alle weiteren Phasen und deren Ergebnisse. Anforderungen sind in der Praxis oft nicht fest oder vollständig bekannt. Dann sind agile Methoden, die auf diesen Umstand Rücksicht nehmen, die bessere Wahl. Aber nehmen wir für den Rest des Texts an, dass dieser Umstand alleine das Wasserfall-Modell noch nicht ausschließt.
Ansätze für Softwareentwicklung können sich nur an dem Erfolg in der Praxis messen lassen. Die Frage ist nun, welche Erfahrungen es zum Wasserfall-Modell gibt.
Das Wasserfall-Modell für die Softwareentwicklung hat den Ursprung in den Fünfzigerjahren. Damals haben die USA das SAGE-System [1] entworfen (Semi-Automatic Ground Environment). Es diente zur Koordination der Luftverteidigung insbesondere gegen einen möglichen Angriff der UdSSR. Im Wesentlichen sollte es ein umfassendes, konsolidiertes Bild aus den verschiedenen Radarstationen erzeugen und dann das Bekämpfen der Ziele koordinieren. Das ist ein Bereich, in dem die Anforderungen relativ klar und unveränderlich sein sollten.
Zu diesem Zeitpunkt gab es keine höheren Programmiersprachen, keine Terminals und kein Time Sharing. Es gab nur Lochkarten und Röhrenrechner. Jedes SAGE Direction Center bekam einen AN/FSQ-7 Computer [2]. Das waren damals die leistungsfähigsten Computer mit einer Fläche von 2.000 m2, 49.000 Röhren, 75.000 Instruktionen pro Sekunde und einem Magnetkernspeicher von 65.536 32-Bit-Wörtern.
Weil Hardware damals um viele Größenordnungen teurer und weniger leistungsfähig war als heute, mussten Projekte bei der Unterstützung der Entwicklung viel sparsamer mit Rechenzeit umgehen. Daher können moderne Softwareentwicklungsprozesse viel mehr Rechenzeit für die Unterstützung von Entwickler:innen aufwenden.
Das SAGE-Projekt war kostspieliger als das Manhattan-Projekt zum Bau der Atombombe, gegen dessen Resultat es ja schützen sollte. Wesentliches Ergebnis war die Software mit insgesamt 0,5 Millionen Instruktionen. Ein Viertel des Codes ist das eigentliche System, der Rest diente zur Unterstützung der Entwicklung.
1956 beschrieb Herbert Benington die grundlegenden Ideen zur Implementierung dieses Systems. Das Paper beschreibt, in welchen Phasen die Implementierung stattfinden soll, und einen linearen Ablauf durch diese Phasen wie in einem Wasserfall-Modell. Diese Beschreibung nimmt jedoch nur circa zwei Seiten ein und stellt lediglich einen Teil der vorgestellten Arbeitsweisen dar. Darüber hinaus diskutiert es unter anderem eine Art Architektur und verschiedene Werkzeuge zur Entwicklung von Systemen.
Prinzipiell sind die Anforderungen für die SAGE-Software wahrscheinlich im Wesentlichen fest, sodass ein solches Modell nicht unsinnig erscheint. Auch wenn der Prozess in dem Paper nicht "Wasserfall-Modell" genannt wird, zeigt sich scheinbar ein relativer Erfolg des Wasserfall-Modells. Schließlich hat das Projekt Software geliefert, die auch genutzt wird, auch wenn das Projekt die ursprüngliche Deadline um ein Jahr gerissen hat.
1983 wurde das Paper erneut in den "IEEE Annals of the History of Computing [3]" veröffentlicht. Der Herausgeber macht dabei eine wichtige Bemerkung: SAGE war eines der ersten Systeme, das so groß war, dass es eine Person alleine nicht mehr entwickeln und verstehen konnte, während vorher einzelne Personen Programme sehr erfolgreich entworfen und geschrieben haben. Es war also der Beginn der Herausforderung, welche heute die Softwareentwicklung dominiert: ein komplexes Softwaresystem mit einem Team koordiniert umzusetzen.
Noch interessanter als diese Ausführung des Herausgebers ist das Vorwort des Autors zur Wiederveröffentlichung. Das SAGE-Projekt hat zunächst einen Prototypen mit 35.000 Instruktionen geschrieben. Das alleine ist schon eine wesentliche Abwandlung des einfachen Wasserfall-Modells, da für diesen Prototypen alle Phasen einmal durchlaufen werden müssen, während der einfache Wasserfall nur einen einmaligen Durchlauf vorsieht. Zwanzig Personen haben dieses Prototypen entwickelt, durch den alle Module, Schnittstellen und Performance-Anforderungen klar waren. Diese Personen haben die Implementierung des eigentlichen Systems wesentlich beeinflusst.
Außerdem steht im Vorwort weiter, dass der größte Fehler des Projekts der Sprung von 35.000 Instruktionen im Prototypen zu mehr als 100.000 Instruktionen im realen System war. Im Nachhinein wäre es sinnvoller gewesen, ein "Framework" für 250.000 Instruktionen zu schaffen, als den 35.000-Instruktionen-Prototypen in dieses "Framework" einzugliedern und weiterzuentwickeln. So hätten schätzungsweise 50 Prozent der Kosten eingespart werden können. Das ist dann aber kein einfacher Wasserfall mehr, weil Code für neue Funktionalitäten ergänzt wird, sodass mindestens Phasen wie Design, Implementierung und Verifikation mehrmals durchlaufen werden.
Die Erfahrungen mit einem der ersten komplexen Softwareentwicklungsprojekte legt also schon nahe, dass ein einfacher Wasserfall keine Lösung für Softwareentwicklung ist – und das trotz relativ klarer Anforderungen.
Abgesehen davon war das SAGE-System einschließlich der Röhrenrechner bis in die Achtzigerjahre in Gebrauch. Aufgrund des technologischen und sonstigen Wandels über die Jahrzehnte scheint die Bezeichnung "Wartung" für diese Phase unzureichend. In dieser Zeit sind sicherlich auch neue, wesentliche Features entstanden. Dazu müssen die Phasen aus dem einfachen Wasserfall wie Anforderung, Design und Implementierung erneut durchlaufen werden.
Manchmal wird die Erfindung des Wasserfalls auch Winston Royce zugeschrieben, der 1970 ein Paper zu seinen Erfahrungen mit Softwareentwicklung großer Systeme [4]verfasst hatte. Royce arbeitete im Bereich Luft- und Raumfahrt, in welchem Anforderungen eher stabil sind und eine weitestgehende Fehlerfreiheit von Anfang an wünschenswert erscheint. Also ein Bereich, für den das einfache Wasserfall-Modell sinnvoll sein könnte. Und tatsächlich findet sich eine Abbildung in dem Paper, die dem einfachen Wasserfall gleicht – der Name "Wasserfall-Modell" taucht allerdings nicht auf.
Aber auch hier zeigt der Rest des Papers mehrere wesentliche Abwandlungen vom reinen Wasserfall, zum Beispiel:
Dementsprechend finden sich in dem Paper weitere Abbildungen, die andere, wesentlich vom einfachen Wasserfall abweichende Prozesse beschreiben.
In seinem Buch "The Leprechauns of Software Engineering [5]" setzt sich Laurent Bossavit mit verschiedenen Mythen im Bereich der Softwareentwicklung auseinander. Das Buch ist ein Plädoyer dafür, fundamentale Grundlagen der Softwareentwicklung kritisch zu hinterfragen.
Ein Kapitel beschäftigt sich mit dem Wasserfall-Modell. Dabei setzt sich Bossavit vor allem mit der Interpretation des Royce-Papers auseinander. Seiner Meinung nach sehen Verfechter der agilen Bewegung das Wasserfall-Modell als eine Fehlinterpretation des Royce-Papers. Der Sichtweise der Agilisten nach hat das Paper eigentlich einen agil-iterativen Ansatz proklamiert. Dabei fehlt dem Royce-Prozess aber in Wirklichkeit ein erneuter Durchlauf der Anforderungsphase.
Kritiker der agilen Bewegung sehen den einfachen Wasserfall als ein Modell, das niemand proklamiert, sondern welches nur zum Diskreditieren formaler Prozesse dient. Royces Modell ist schließlich nicht so unflexibel und empfiehlt auch keinen einmaligen, sequenziellen Durchlauf durch die Phasen. Tatsächlich sind laut Bossavit aber beide Interpretationen ungenügend.
Bossavit zeigt weiter, dass Royces Paper zumindest eine Quelle der bekannten grafischen Darstellung des Wasserfalls ist. Es wurde populär, weil Barry Boehm und seine Firma TRW in den Achtzigern dieses Paper als Rechtfertigung für existierende Top-down-Ansätze begriffen und entsprechend zitierten. Sie publizierten das Royce- und das SAGE-Paper erneut. Wenig später führte Boehm das iterativ-inkrementelle Spiral-Modell ein und interpretierte das Royce-Paper als dessen Vorläufer, da es ja schon eine Prototypphase etabliert hatte. So weist Bossavit darauf hin, dass Boehm auch eine wichtige Rolle in der Geschichte des Wasserfall-Projekts spielt. Wie Benington und Royce zuvor empfiehlt auch Boehme den einfachen Wasserfall nicht, sondern entwickelt ihn weiter.
Teilweise werden US-Militärstandards als weitere Quellen für Wasserfall-Vorgehen zitiert. Genau genommen diskutiert MIL-STD-490a von 1985 jedoch Spezifikationen und MIL-STD-483a von 1985 Konfigurationsmanagement. MIL-STD-2167 (1985) definiert Softwareentwicklungsstandards. Dort ist tatsächlich von einem Softwareentwicklungszyklus mit verschiedenen Phasen die Rede. Dieser Zyklus kann jedoch laut Abschnitt 4.1.1 in mehreren Iterationen durchgeführt werden und die Phasen sollen sich typischerweise überlappen. Auch das ist nicht unbedingt ein einfacher, sequenzieller Durchlauf, wie ihn der einfache Wasserfall vorsieht. Es ist natürlich vorstellbar, dass ältere Revisionen der Standards oder ältere Standards sich unterscheiden, aber über 35 Jahre alte Empfehlungen im Bereich Softwareentwicklung sind vermutlich nicht mehr der Stand der Technik.
Wenn man Wikipedia [6] trauen kann, ist es auch beim deutschen V-Modell-Entwicklungsstandard der öffentlichen Hand möglich, “die Aktivitäten des V-Modells zum Beispiel auf ein Wasserfallmodell oder ein Spiralmodell abzubilden”. Das V-Modell XT von 2005 orientiert sich sogar an agilen und inkrementellen Ansätzen. Auch mit diesen Modell ist ein ein einfacher Wasserfall also nicht zwingend.
Die Personen, denen das einfache Wasserfall-Modell zugeschrieben wird, haben es weder erfunden noch proklamierten sie es. Und das trotz Umgebungen, in denen Anforderungen vermutlich relativ fest sind und ein rigider Prozess noch sinnvoll war, um die bestehenden Limitationen beispielsweise bei der für die Entwickler:innen bei der Entwicklung nutzbaren Hardware einzuhalten.
Natürlich ist es denkbar, auch mit einem einfachen Wasserfall-Prozess erfolgreich zu sein – aber spätestens seit Royce und damit seit 50 Jahren sind andere Vorgehensmodelle zu empfehlen. Eigentlich sind diese Probleme aber schon seit dem SAGE-Projekt und damit seit Anbeginn der Softwareentwicklung im Team klar.
Wenn Anforderungen sich ändern, hat dieser Prozesse weitere offensichtliche und erhebliche Schwächen, da man dann bei einer wesentlichen Änderung im Prinzip von vorne anfangen müsste. Wer also einen einfachen Wasserfall empfiehlt, versteht den Stand der Technik vor 50 beziehungsweise 65 Jahren nicht. Und in diesen Jahrzehnten hat sich die Technologie weiterentwickelt, was viele Dinge wesentlich vereinfacht und es erlaubt, den Entwicklungsprozess selbst besser mit Software zu unterstützen. Das benachteiligt Wasserfall-artige Prozesse weiter.
Der einfache Wasserfall dient vermutlich in erster Linie als Gegenmodell zu Agilität und damit als ein Beispiel, wie man es nicht machen sollte. Das ignoriert aber die Abwandlungen, die von Anfang an genutzt wurden.
Vielleicht ist es auch verführerisch, endlich einen "sauberen" Prozess durchzuführen. Es mag intuitiv sinnvoll erscheinen, Dinge zu Ende zu führen, zu konsolidieren und dann darauf aufzubauen. Auch ich habe mich schon dabei ertappt, ein solches Vorgehen nach Phasen als "eigentlich richtigen" und "sauberen" Weg zu bewerten. Auch kann ein einfacher Wasserfall eine Illusion von Kontrolle geben: Es gibt eine klare Aufteilung in Phasen mit klaren Ergebnissen. Aber Probleme werden oft erst offensichtlich, wenn Software ausgeliefert wird und Benutzer die Software tatsächlich verwenden. Dieses Feedback verzögert der einfache Wasserfall, weil erst alle Phasen vollständig abgeschlossen sein müssen, statt möglichst schnell eine teilweise Lösung auszuliefern und Feedback dazu einzusammeln.
Zum Abschluss ein Vorschlag für ein Experiment: Wenn jemand das nächste Mal einen Wasserfall-Prozess vorschlägt, fragen Sie die Person, wer den Prozess erfunden und empfohlen hat.
Der einfache Wasserfall-Prozess war vor 65 Jahren schon nicht zu empfehlen – und damals fing Softwareentwicklung im Team erst an. Recherche in Original-Quellen ist hilfreich.
Vielen Dank an meine Kolleg:innen Lena Kraaz, Martin Kühl, Tammo van Lessen, Torsten Mandry, Jörg Müller, Joachim Praetorius, Gernot Starke und Stefan Tilkov für die Kommentare zu einer früheren Version des Artikels.
URL dieses Artikels:https://www.heise.de/-4878614
Links in diesem Artikel:[1] https://en.wikipedia.org/wiki/Semi-Automatic_Ground_Environment[2] https://en.wikipedia.org/wiki/AN/FSQ-7_Combat_Direction_Central[3] https://web.archive.org/web/20110718084251/http://sunset.usc.edu/csse/TECHRPTS/1983/usccse83-501/usccse83-501.pdf[4] http://www-scf.usc.edu/~csci201/lectures/Lecture11/royce1970.pdf[5] https://leanpub.com/leprechauns/[6] https://de.wikipedia.org/w/index.php?title=V-Modell_(Entwicklungsstandard)&oldid=201987938
Copyright © 2020 Heise Medien
Softwaresysteme sind kompliziert. Best Practices für den Systementwurf könnten dabei helfen, die Komplexität möglichst einfach zu bändigen. Leider nützen sie wenig.
Dave Snowden teilt mit dem Cynefin [1]-Framework [2] Probleme, Systeme und Aufgaben in unterschiedliche Domänen ein:
Diese Blog-Post kann keine vollständige Einführung in das Cynefin-Framework sein. Aber aus dem Cynefin-Framework ergibt sich, dass Best Practices nur bei einfachen Systemen mit klaren Ursache-Wirkung-Beziehungen sinnvoll sind. Softwaresysteme sind jedoch in den meisten Fällen nicht nur technologisch komplex: Die Entwicklung findet in einem komplexen sozialen System statt, in dem die verschiedenen Rollen im Entwicklungsteam mit den Stakeholdern interagieren. Wie das technologische Softwaresystem auf der einen und die soziale Entwicklungsstruktur auf der anderen Seite miteinander interagieren, lässt sich schwer vorhersagen. Wir reden also von komplizierten oder komplexen Systemen. Es mag Ausnahmen geben, aber einfache Systeme rechtfertigen wohl kaum den Aufwand für die Implementierung von Individualsoftware, weil die Probleme eben einfach lösbar sind – beispielsweise durch Standardsoftware.
Wenn Softwareprojekte aber komplex oder kompliziert sind, dann gibt es in der Softwareentwicklung im Wesentlichen nur Good Practices oder gar Emergent Practices. Wer also einfach Ansätze aus einem anderen Kontext übernimmt und auf Best Practices setzt, wählt gegebenenfalls eine für diese Aufgabe ungeeignete Lösung. Wir arbeiten an einer Aneinanderreihung von unterschiedlichen, speziellen Herausforderungen und müssen uns jedes Mal auf diese andere Umgebung passend einstellen und Lösungen anbieten, die den aktuellen Herausforderungen gerecht werden.
Wer dennoch auf Best Practices setzt, macht es den am Projekt Beteiligten schwer, die gewählten Ansätze zu hinterfragen. Schließlich sind es ja Best Practices. Aber in Wirklichkeit können sie eben ungeeignet sein, weil man in einer anderen Domäne ist. Daher finde ich Aussagen wie "Microservices sind eine Architektur-Best-Practice" oder "Monolithen sind eine Architektur-Best-Practice" nicht hilfreich. Aber natürlich ist es sinnvoll, sich mit Ansätzen zu beschäftigen, die in einem bestimmten Kontext erfolgreich waren, und davon zu lernen.
Der Umgang mit Good oder Best Practice kann auch darüber hinaus problematisch sein. In einem mir bekannten Projekt haben Architekt:innen Schnittstellen, die nur zwei Teams nutzen, als Best Practice kommuniziert. Da immer nur zwei Teams beteiligt sind, können die Schnittstellen einfacher geändert und abgestimmt werden, als wenn mehrere Teams die Schnittstellen nutzen. Wenn man also mehreren Teams Funktionalitäten anbieten will, kann man für jedes Team eine Schnittstelle umsetzen, um so unabhängig zu arbeiten.
Eines der Teams in dem Projekt hatte diese Idee befolgt, obwohl die Schnittstellen relativ ähnlich waren und sich absehbar nicht ändern würden. Der Vorteil der Unabhängigkeit bei Änderungen ist also in diesem Fall unerheblich. Dennoch hat das Team keine einheitliche Schnittstelle umgesetzt. Diese Alternative hatte das Team selbst als bessere bewertet. Ohne die kommunizierte Best Practice der Architekt:innen hätte das Team vielleicht schon früher den eigenen, besseren Ansatz nutzen können. Denn natürlich hat der Ansatz mit vielen Schnittstellen Nachteile. Es entsteht so eine Vielzahl von Schnittstellen, die gewartet und implementiert werden müssen.
Die kommunizierte Best Practice ist vielleicht also nur eine Good Practice – oder der Kontext, in dem sie eine Best Practice ist, muss genauer definiert werden. Der zentrale Punkt ist, dass kommunizierte Best oder Good Practices dazu verleiten, diesen Beispielen einfach zu folgen und eigene, bessere Lösungen nicht zu nutzen. Daher sollte man solche Ansätze immer kritisch hinterfragen.
Entscheidungsvorlagen mit Kernfragen sind flexibler und können bei der Entscheidung zwischen verschiedenen Best oder Good Practices helfen. Solche Vorlagen finden viele nützlich, aber auch sie schränken den Lösungsraum ein, weil sie niemals alle denkbaren Fälle abdecken können.
Am Ende werden also die am Projekt Beteiligten individuelle Entscheidungen treffen und verantworten müssen. Sie müssen sie auch begründen. Sich hinter einer Best Practice oder einem "Das macht man heute so!" zu verstecken, ist nicht ausreichend.
Außerdem gibt es unterschiedliche Good Practices. Wenn also jemand einen Ansatz wählt, der vom eigenen bevorzugten Ansatz abweicht, kann das immer noch eine Good Practice sein – oder gar eine Emergent Practice, die speziell auf die Herausforderung angepasst ist. Dann sollte man sich davon verabschieden, die eigene “Best Practice” zu empfehlen. Natürlich kann der gewählte Ansatz gar keinen Sinn ergeben – dann kann man sicherlich einen anderen empfehlen.
Softwareentwicklung ist oft für Best Practices zu komplex. Sie können zwar Orientierung geben, werden sie aber ohne kritische Reflektion angewendet, können für die spezifische Herausforderung suboptimale Architekturentwürfe entstehen.
Vielen Dank an meine Kolleg:innen Robert Glaser, Anja Kammer, Martin Kühl, Joachim Praetorius und Hermann Schmidt für die Kommentare zu einer früheren Version des Artikels.
URL dieses Artikels:https://www.heise.de/-4872398
Links in diesem Artikel:[1] https://de.wikipedia.org/wiki/Cynefin-Framework[2] https://www.cybay.de/blog/das-cynefin-framework/
Copyright © 2020 Heise Medien
Wenn man auf Entwickler*innen nicht aufpasst, machen sie den ganzen Tag Unsinn. Wie soll man damit umgehen?
Relativ häufig wird mir die Frage gestellt: "Wie kontrolliert man die Technologieauswahl im Team?" In der Diskussion zeigt sich dann die Meinung, dass Entwickler*innen Technologieentscheidungen eigentlich nicht treffen sollten. Das Projekt würde sonst in Chaos und Anarchie versinken, weil alle denkbaren Technologien genutzt werden. Developer sind schließlich verantwortungslose Spielkinder! Die Leidtragenden, wenn Projekte in Chaos und Anarchie versinken, sind aber Entwickler*innen. Es ist also in ihrem besten Interesse, Technologien mit Augenmaß zu nutzen. Das spielt in der Diskussion aber nur selten eine Rolle.
Die nächste Eskalationsstufe sind Äußerungen wie "Meine 14-jährige Tochter programmiert auch und die bekommt das schneller hin als diese Entwickler" oder "Mit den Entwicklerinnen hier kann man moderne Ideen eh nicht umsetzen". Entwickler*innen sind hochqualifizierte Expert*innen. Software gehört zum Komplexesten, was Menschen überhaupt produzieren können. Ich halte solche Äußerungen schlicht für respektlos.
Aber nehmen wir an, dass Developer tatsächlich verantwortungslose Spielkinder sind. Dann kann man anscheinend nur auf Kontrolle setzen. Das führt zu klaren Richtlinien, beispielsweise bezüglich zu nutzender Technologien oder Coding-Standards, idealerweise mit automatisierter Überprüfung.
Sicherlich können solche Maßnahmen sinnvoll sein. Aber die Kontrollen funktionieren oft nur schlecht: In einem meiner ersten Großprojekte haben wir gemeinsam einige Coding-Richtlinien festgelegt und mit Werkzeugen automatisiert überprüft. Nach einiger Zeit gab es keine Verstöße, aber nur scheinbar: In Wirklichkeit hatten einige Entwickler*innen die Werkzeuge an bestimmten Code-Stelle einfach deaktiviert. So kann ein sinnloser Wettlauf mit zunehmend mehr Kontrolle und dem Unterwandern der Kontrollen beginnen.
Offensichtlich kommt man so also nicht weiter. Und Kontrolle skaliert auch nicht: Man kann nicht als einzelne Person alles verstehen, kontrollieren und korrigieren, was ein ganzes Team produziert. Wer den Anspruch an sich hat, der muss scheitern. Passend dazu zeigt die in diesem Blog schon einmal zitierte empirische Untersuchung in der “State of DevOps”-Studie [1], dass ein schwergewichtiger Änderungsprozess die Leistungsfähigkeit der Softwareentwicklungsorganisation negativ beeinflusst. Mehr Kontrolle und Overhead sind also wohl kaum die Lösung.
Von Fred George habe ich sinngemäß einen Satz im Ohr: "Developer wollen an Dingen tüfteln. Also gib ihnen Dinge zum Tüfteln!" Daraus leitet er in seinem Modell weitgehende Freiheiten für Entwickler*innen ab. Außerdem tüfteln sie dann nicht nur am Code, sondern direkt an Geschäftszielen wie Umsatzsteigerung oder Kundenzufriedenheit. Bezeichnenderweise heißt das Modell "Developer Anarchy". Wie kann das funktionieren? Schließlich sind Developer doch verantwortungslose Spielkinder!
Vielleicht sind sie doch verantwortungsvolle Personen? Immerhin kenne ich durchaus einige Entwickler*innen, die im privaten Leben erhebliche Budgets auf eigenes Risiko verwalten – beispielsweise beim Hausbau. Ihre Fähigkeiten sind ihnen auch wichtig. Sie programmieren auch in ihrer Freizeit [2]oder nehmen zum Beispiel an abendlichen Meetups oder an Coderetreats [3] an Wochenenden teil. Das zeugt von einer hohen Motivation, die eigenen Fähigkeiten sogar in der Freizeit ständig weiterzuentwickeln.
Meiner Meinung nach ist der einzige Weg aus dieser Situation, zunächst einmal Respekt vor Entwickler*innen und ihren Qualifikationen aufzubauen. Ich nehme sie als Spezialist*innen für Code wahr – was sie auch sind.
Vertrauen und Delegation können das Verhalten ändern und eine Voraussetzung für verantwortungsvolles Handeln sein. Wenn Entwickler*innen in ihren Augen sinnlose Entscheidungen umsetzen müssen, werden sie versuchen, diese Entscheidungen zu unterlaufen. Wenn das gesamte Projekt sinnlos erscheint, werden sie sich Ecken suchen, in denen sie herumspielen können. Wenn Entwickler*innen aber selbst Entscheidungen treffen, werden sie sich anders verhalten müssen. Sie können nicht einfach nur kritisieren, sondern müssen selbst konstruktiv sein. Außerdem müssen sie mit den Konsequenzen leben – also werden sie sich die Entscheidungen gut überlegen.
Als Bezeichnung für einen Schritt hin zu mehr Vertrauen finde ich "Leap of Faith" (Sprung des Glaubens) gut: Man glaubt an die Entwickler*innen und springt ins Unbekannte, was natürlich Mut erfordert.
Wenn ihr Vorgehen optimierbar ist, hilft Kontrolle eben nicht weiter, denn diese lässt sich halt unterlaufen. Stattdessen sollten Wissensaustausch und -transfer im Fokus stehen. Wenn Entwickler*innen sowohl die Ziele als auch ihre technische Umsetzung verstanden haben, gibt es eine relativ hohe Wahrscheinlichkeit, dass sie die Konzepte der technischen Umsetzung auch befolgen. Und wenn nicht: War es vielleicht doch keine gute Idee? Vielleicht haben sie sogar eine bessere? So kann es offene, produktive Diskussionen und Verbesserungen geben.
So tritt an die Stelle von Kontrolle eine Zusammenarbeit, bei der unterschiedliche Sichtweisen der Beteiligten ausgetauscht werden und so sogar noch bessere Lösungen entstehen, als dies durch Kontrollen alleine möglich wäre. Entwickler*innen sind eben auch Spezialist*innen für ihren Bereich.
Nun kann man natürlich sagen, dass Management und Architekt*innen endlich den Entwickler*innen gegenüber den nötigen Respekt und das nötige Vertrauen zollen müssen – und damit ist das Problem endlich gelöst!
Respekt ist aber keine Einbahnstraße. Entwickler*innen müssen auch Management und Architekt*innen Respekt entgegenbringen und ihnen vertrauen. Sonst sind wohl kaum Diskussionen auf Augenhöhe möglich. Sie sind ebenfalls Expert*innen – nur eben in anderen Bereichen. Architekt*innen können beispielsweise größere Systeme strukturieren und das Management sich um die Organisation kümmern.
Wechselseitiger Respekt und Vertrauen sind die Grundlage für erfolgreiche Zusammenarbeit.
Vielen Dank an meine Kolleginnen und Kollegen Christoph Iserlohn, Robert Glaser, Anja Kammer, Michel Krämer, Martin Kühl, Stefan Tilkov, Hermann Schmidt und Benjamin Wolf für die Kommentare zu einer früheren Version des Artikels.
URL dieses Artikels:https://www.heise.de/-4786297
Links in diesem Artikel:[1] https://cloud.google.com/devops/state-of-devops/[2] https://www.heise.de/news/Studie-Entwickler-programmieren-in-der-Freizeit-weiter-4782219.html[3] https://www.coderetreat.org/
Copyright © 2020 Heise Medien
In der Softwarearchitektur nimmt die Diskussion von Zielbildern viel Platz ein – schließlich muss es ein Ziel geben, auf das man hinarbeitet. Aber die Prioritäten sollten anders verteilt sein, und eigentlich sind Zielbilder auch nicht das Ziel.
Zielbilder stellen dar, wie eine Architektur idealerweise aussehen sollte und in welche Teile das System zerlegt werden soll. Der Entwurf einer solchen Architektur scheint die zentrale Architekturherausforderung zu sein: kein Wunder, dass Teams dieser Aufgabe so viel Zeit einräumen.
In den meisten Fällen ist aber schon eine Architektur vorhanden. Eine neue muss eigentlich die vorhandene Architektur als Rahmenbedingungen für den Entwurf mitbetrachten. Dennoch erscheint eine Zielarchitektur sinnvoll: Schließlich muss man wissen, auf welches Ziel man hinarbeiten muss. Die vorhandene Architektur dabei mitzubetrachten, kann dazu verleiten, die Fehler der Vergangenheit zu wiederholen.
Wenn das Zielbild fertig ist, muss man die Frage nach der Umsetzbarkeit stellen: Wann lässt sich das Zielbild mit welchem Aufwand erreichen? Spätestens an dieser Stelle wird oft klar, dass ein Zielbild alles andere als einfach zu erreichen ist. Aber das war auch gar nicht die Idee beim Entwurf des Zielbilds: Es soll eine Architekturutopie darstellen, die daher nicht realistisch erreichbar sein muss.
Die Diskussion über das Zielbild ist jedoch nur dann sinnvoll, wenn sie Auswirkungen auf das Projekt hat. Das Zielbild hat oft kaum noch etwas mit der aktuellen Situation zu tun. Es gibt also unzählige Stellen, an denen man auf das Zielbild hinarbeiten kann. Wo aber anfangen?
Für eine Zielbilddiskussion drängt sich der Vergleich mit einer Expedition zu einem Berggipfel auf: Natürlich ist es sinnvoll, einen Blick auf den Berggipfel in der Ferne zu werfen, um zu schauen, ob man in die richtige Richtung unterwegs ist. Aber noch wichtiger sind der nächste Schritt und der nächste Fluss oder das nächste Hindernis, das es zu überwinden gilt.
Die Metapher der Expedition nimmt an, dass man das Zielbild, also den Berggipfel, erreichen wird. Bei einem Architekturzielbild ist das nicht unbedingt so: Ich jedenfalls sehe praktisch nie Projekte, die das Zielbild erreicht haben. Das kann aber daran liegen, dass Berater*innen nur dann gebraucht werden, wenn es gilt, etwas zu verbessern, und daher kaum perfekte Projekte sehen.
Wichtiger als eine Diskussion zum Erreichen eines Zielbilds finde ich daher konkrete Maßnahmen, um in einem Projekt besser zu werden. Solche Aktivitäten müssen nicht auf die Strukturierung des Systems begrenzt sein, wie es der Begriff "Zielbild" nahelegt, sondern es können ganz unterschiedliche Aktivitäten im Bereich von Entwicklung, Betrieb oder auch Anforderungsmanagement sein. Solche Maßnahmen sind im Gegensatz zu einem Zielbild tatsächlich umsetzbar und bringen schon kurzfristig einen Nutzen.
Eigentlich ist ein Zielbild sogar verzichtbar. Die Stakeholder eines Systems interessieren sich für Features und Qualitäten der Software wie Performance oder Sicherheit. Der interne Aufbau, den ein Zielbild zeigt, ist nur wichtig, wenn er Qualitäten wie die Wartbarkeit beeinflusst. Das Zielbild beeinflusst viele wichtige Qualitäten wie Benutzerfreundlichkeit gar nicht. Die Features und Qualitäten sind eigentlich die Ziele des Projekts. Sie haben sogar weitergehende Konsequenzen: Qualitäten wie Benutzerfreundlichkeit können wesentlich für den Erfolg eines Produkts oder gar einer Firma sein.
Die meisten Architekturdokumentationen, die ich bei Reviews oder Beratungen sehe, zeigen eine Aufteilung des Systems oder ein Zielbild, oft sogar als Hauptartefakt. Die Ziele des Projekts und die daraus abgeleiteten Features und Qualitäten finden sich nur sehr selten, obwohl sie wichtiger wären. Und genau hier wäre eine Zieldiskussion angebracht: Was soll das Projekt erreichen? Welche Features und Qualitätsziele müssen erfüllt sein? Das führt zu einem besseren Verständnis für die Domäne und damit zu einer besseren Grundlage für das Projekt.
Und dann sollte es Maßnahmen geben, um die Qualitätsziele auch tatsächlich zu erreichen. Auch das kommt in den meisten Projekten zu kurz. Schließlich mag Benutzerfreundlichkeit ja wichtig sein, aber es in der Architektur zu betrachten, unterbleibt dann doch oft.
Vielleicht ist das also der Berggipfel, den wir in Wirklichkeit in Augenschein nehmen und dann erklimmen sollten.
Vielen Dank an meine Kolleginnen und Kollegen Anja Kammer und Martin Otten für die Kommentare zu einer früheren Version des Artikels.
Diskussionen über Zielbilder können zwar hilfreich sein, aber nur konkrete Maßnahmen führen zu einer wirklichen Verbesserung. Und wichtiger als ein Architekturzielbild ist Klarheit über das Ziel des Projekts.
URL dieses Artikels:https://www.heise.de/-4772393
Copyright © 2020 Heise Medien
Metaphern für Softwareentwicklung gibt es viele. Sie als Spiel zu begreifen, scheint zunächst respektlos. Wenn man tiefer gräbt, ergeben sich aber zahlreiche Parallelen.
Der Begriff "Spiel" steht erst mal für Spaß. Softwareentwicklung ist aber kein Spaß – es geht meistens um ernsthafte Geschäftsziele und oft hohe Budgets. So etwas ist kein Spiel.
Die Spieltheorie [1] ist allerdings eine wissenschaftlich anerkannte Theorie, die sich mit Strategien für Spiele und andere Entscheidungssituationen beschäftigt. Diese Theorie hat viele Anwendungen. Auch Kriege oder Vorgehen in der Wirtschaft werden spieltheoretisch untersucht und so bessere Strategien entwickelt.
Spiele scheinen außerdem trivial zu sein. Schließlich spielen schon Kinder. Aber auch hier liegen bei näherer Betrachtung die Dinge anders. Einige Profis widmen ihr ganzes Leben Spielen wie Schach oder dem asiatischen Spiel Go [2]. Es gibt viel mehr denkbare Go-Stellungen (ca. 10^170) als Atome im Universum (ca. 10^80). Das ist alles andere als trivial.
Softwareentwicklungsprojekte als Spiele zu betrachten, führt zu einigen Erkenntnissen:
Spiele haben Gewinnbedingungen. Jede Aktivität sollte auf die Gewinnbedingungen einzahlen und man muss kollaborieren. Das hilft auch bei Softwareentwicklung.
Vielen Dank an meine Kolleginnen und Kollegen Hanna Prinz, Tobias Erdle und Sonja Scheungrab für die Kommentare zu einer früheren Version des Artikels.
URL dieses Artikels:https://www.heise.de/-4659442
Links in diesem Artikel:[1] https://de.wikipedia.org/wiki/Spieltheorie[2] https://de.wikipedia.org/wiki/Go_(Spiel)[3] https://www.heise.de/developer/artikel/Ueber-die-optimale-Softwarearchitektur-3785166.html[4] https://de.wikipedia.org/wiki/Pandemie_(Spiel).
Copyright © 2020 Heise Medien
Große komplexe Projekte sind schwer zu handhaben. Software-Release-Trains sind eine Lösung zur Koordination. Aber der Ansatz läuft Selbstorganisation und modernen Management-Konzepten zuwider.
Ein Release Train [1] dient zur Koordination mehrerer abhängiger Projekte. Im Rahmen dessen entwickeln alle Projekte aufeinander abgestimmte Versionen, die Phasen wie Beta-Testing, Release oder Updates gemeinsam durchlaufen. Die Idee hat sich in vielen großen Projekte wie Eclipse, Ubuntu, dem Spring Framework oder LibreOffice bewährt.
Das Scaled Agile Framework (SAFe) schlägt einen Agile Release Train [2] vor, um die Arbeit mehrerer agiler Teams zu koordinieren. Sie haben einen festen Zeitpunkt, zu dem sie liefern, und bieten alle zwei Wochen ein neues Systeminkrement mit einer System-Demo. Der Agile Release Train koordiniert die Entwicklung der Software und dann das Release, nach dem Nutzer die neuen Features verwenden können. Also geht es darum, die Entwicklung eines oder mehrerer größeren Features über mehrere Teams zu koordinieren. Das Ziel ist es, dass nicht nur die einzelnen Teams, sondern auch das gesamte System regelmäßig neue Features ausrollt. So sollen mögliche Probleme bei den größeren Features offenbar werden. Natürlich gibt es für einen Agile Release Train diverse Rollen für eine zentrale Koordination.
Koordination ist für eine Zusammenarbeit immer notwendig, aber es erzeugt auch einen Overhead. Eine zentrale Koordination steht in einem Widerspruch dazu, möglichst viel Verantwortung zu delegieren. Moderne Organisationen sollten möglichst wenig Hierarchien haben und die Teams sollten selbstorganisiert arbeiten, statt auf die zentrale Koordination und ein Command & Control angewiesen zu sein. Ohne eine zentrale Kontrolle skaliert die Organisation außerdem besser.
Übermäßige Koordination ist zwar ein organisatorisches Problem, aber die Ursache kann ein Architektur-Problem sein: Wenn Änderungen, die für einen Kunden einen Wert darstellen, die Koordination mehrerer Teams und Komponenten erfordern, kann ein besserer fachlicher Schnitt die Anzahl der beteiligten Komponenten und damit der Teams reduzieren. Domain-driven Design [3] schlägt dafür einige Maßnahmen vor. Wenn die Koordination in einem Agile Release Train sehr kompliziert ist, dann lohnt es sich auf jeden Fall, einen Blick auf die Architektur zu werfen und zu schauen, ob dort Optimierungspotenziale vorliegen.
Aber auch wenn die Softwarearchitektur perfekt ist, können für ein Feature natürlich Änderungen notwendig sein, die mehrere Teams betreffen. Schließlich arbeiten die Teams gemeinsam an einem System, und Features können daher immer auf mehrere Teams verteilt sein. Dafür schlägt Domain-driven Design auch verschiedene Pattern vor. Bei dem Pattern "Customer/Supplier" (Kunde/Lieferant) kann das Customer-Team bei dem Supplier-Team die Implementierung von Features anfordern. Die Alternative ist "Conformist": Dann muss das Team nehmen, was es bekommt, und kann keine Implementierung von Features anfordern.
Also kann ein DDD-Team auch dann ein Feature implementieren, wenn es dazu auf Zulieferungen angewiesen ist. Dazu müssen lediglich die "Spielregeln" zwischen Teams wie Customer/Supplier festgelegt sein. Natürlich kann es gegebenenfalls notwendig sein, noch eine Eskalationsinstanz für Streitigkeiten zu definieren, aber unter normalen Umständen können die Teams so ohne zentrale Koordination arbeiten und sich untereinander dezentral koordinieren.
Die kollaborative Entwicklung von Features ähnlich wie bei einem Agile Release Train gibt es bei DDD auch. DDD beschreibt es als "Partnership". Nun ist eine Partnerschaft eigentlich positiv besetzt. Die englische Ausgabe der DDD-Referenz [4] nutzt zur Illustration von Partnership ein Drei-Bein-Rennen, also ein Rennen, bei dem die Teilnehmer an einem Bein zusammengefesselt sind. Eine solche Partnerschaft und die damit verbundene enge Koordination führen eher zu einem Problem, so wie es bei einem Agile Release Train auch zu erwarten ist.
Eine enge zentralen Koordination, wie sie Agile Release Trains umsetzen, sollte bei einer guten Softwarearchitektur nicht unbedingt notwendig sein und kann mit anderen Mitteln umgangen werden. Vielleicht ist die wahrgenommene Sicherheit ein Grund dafür, dass Ansätze wie SAFe erfolgreich sind. Durch die Koordination wird eine Kontrolle des Fortschritts auf der Ebene des Gesamtprojekts möglich und notwendig. Das kann eine höhere Sicherheit vermitteln. Zuständigkeiten wirklich an Teams zu delegieren erfordert hingegen ein hohes Maß an Vertrauen.
Release Trains koordinieren die Zusammenarbeit verschiedener Teams. Ansätze aus dem Domain-driven Design hingegen delegieren noch mehr Zuständigkeit in die Teams und benötigen daher weniger Koordination
Vielen Dank an meine Kolleginnen und Kollegen Anja Kammer, Martin Kühl, Torsten Mandry, Sebastian Schwaiger und Benjamin Wolf für die Kommentare zu einer früheren Version des Artikels.
URL dieses Artikels:https://www.heise.de/-4598765
Links in diesem Artikel:[1] https://en.wikipedia.org/wiki/Software_release_train[2] https://www.scaledagileframework.com/agile-release-train/[3] https://ddd-referenz.de/[4] https://domainlanguage.com/ddd/reference/
Copyright © 2019 Heise Medien
Agilität in der Softwareentwicklung wird oft unzureichend umgesetzt und gelebt. Hilft sie trotzdem?
Softwareentwicklung ist kompliziert und komplex. Deswegen führen viele Projekte zu Fehlschlägen. Es ist schon schwer genug festzustellen, ob ein Projekt erfolgreich war oder nicht. Die Ziele sind gegebenenfalls nicht klar definiert, aus politischen Gründen können Fehlschläge zu Erfolgen umdefiniert werden und schließlich gibt es verschiedene Parameter, nach denen Erfolg bewertet werden kann. Subjektiv scheint der Anteil der Projekte, die eines oder mehrere der Projektziele nicht erreichen, durchaus signifikant zu sein.
Eine schon lange etablierte Untersuchung über den Erfolg von Projekten ist der Chaos-Report der Standish Group [1]. Er stellt seit 1994 Erkenntnisse über IT-Projekte zusammen. Er verfügt über eine Datenbasis von über 20 Jahren und über 50.000 Projekten. Die Analysten bewerten die Projekte, sodass die Bewertung als Erfolg oder Misserfolg nicht auf den subjektiven Eindrücken der am Projekt Beteiligten basiert. Der Report aus dem Jahr 2015 ist kostenlos erhältlich. Er zeigt, dass schon seit mehreren Jahren circa 20 Prozent der Projekte Fehlschläge sind. Etwa 40 Prozent haben nicht alle Ziele erreicht und weitere 40 Prozent sind erfolgreich. In Kategorien wie Einhalten des Zeitplans, der Kosten oder der Termine erreichen zwischen 40 und 60 Prozent die Ziele nicht. Laut dem Report reduziert Agilität diese Zahlen erheblich, teilweise auf die Hälfte.
Diese Zahlen kann man sicherlich kritisieren: Erfolg ist kaum objektivierbar. Lange hat der Chaos-Report als Erfolgskriterien Budget, Scope und Zeit definiert. Agile Projekte können aber vorab keinen vollständigen Scope definieren, sondern planen nur das nächste Inkrement. Also können echte agile Projekte einen Scope nicht erfolgreich einhalten, weil er am Anfang des Projekts unbekannt ist. Das wirft die Frage auf, wie sich die Einhaltung des Scopes dann überhaupt bewerten lässt, wenn die Projekte tatsächlich agil sind.
Wegen dieser Widersprüche kann es gut sein, dass die "agilen" Projekte aus dem Chaos-Report zwar einige Praktiken umsetzen, aber nicht alle. Aber auch aus anderen Gründen sind Zweifel daran angebracht, ob die "agilen" Projekte wirklich agil sind. So gibt es viele Missverständnisse [2] in diesem Bereich. Viele Projekte nennen sich agil, obwohl sie in Wirklichkeit teilweise fundamentale Konzepte nicht umsetzen. Die agilen Projekte aus dem Chaos-Report sind also wahrscheinlich eher Projekte, die eine "kaputte" Version von Agilität umsetzen. Positiv ausgedrückt: Sie haben angefangen, Agilität zu adaptieren, aber haben noch lange nicht alles Wichtige umgesetzt. Da Agilität ein kontinuierlicher Verbesserungsprozess sein sollte, ist die Adaption von Agilität eigentlich nie vollständig abgeschlossen, aber auch dieser wichtige Aspekt wird oft nicht befolgt.
Wenn es tatsächlich so sein sollte, dass die "kaputte" Umsetzung agiler Mechanismen bereits erhebliche Verbesserungen bei den Projektergebnissen ergibt, dann ist dieser Weg wirtschaftlich auf jeden Fall sinnvoll. Man könnte sogar die Frage stellen, welchen weiteren wirtschaftlichen Vorteil die vollständige und korrekte Umsetzung von Agilität ergibt. Für solche wirtschaftlichen Vorteile gibt es aber durchaus gute Indizien [3]. Aber die Umsetzung vollständiger Agilität – und vor allem der agilen Werte – könnte aufwendig sein, ohne dass es dafür einen entsprechenden wirtschaftlichen Vorteil gibt. Dann könnten die teilweise sehr schlecht umgesetzten agilen Prozessen bezüglich der Kosten-Nutzen-Abwägung wirtschaftlich nahezu optimal sein, weil sie relativ leicht zu erreichen sind und bereits erhebliche Vorteile bieten.
Um es mit Voltaire zu sagen: Das Bessere – also "echte" Agilität – ist eben der Feind des Guten – also "kaputte" Agilität. Man wird also eine weitere Verbesserung nur erreichen, wenn man sich nicht mit etwas zufrieden gibt, das bereits ausreichend gut ist. In der Folge könnten kaputte agile Prozesse ein Dauerzustand werden. Das mag zwar wirtschaftlich sinnvoll sein. Aber es sind nur bedingt positive Aussichten, weil "kaputte" Prozesse demotivieren und oft gerade Werte und Kultur leiden – und darunter leiden dann oft auch Menschen. Hoffen wir also, dass es nicht so ist.
Wenn "kaputte" Agilität schon deutliche Vorteile bringt, erklärt das, warum die Prozesse oft kaputt sind und warum sie nicht noch weiter verbessert werden.
Vielen Dank an meine Kolleginnen und Kollegen Anja Kammer, Martin Kühl und Hanna Prinz für die Kommentare zu einer früheren Version des Artikels.
URL dieses Artikels:https://www.heise.de/-4599441
Links in diesem Artikel:[1] https://www.standishgroup.com/[2] https://www.heise.de/developer/artikel/Die-Perversion-agiler-Metaphern-4466436.html[3] https://www.heise.de/developer/artikel/Das-Problem-mit-der-Agilitaet-4140080.html
Copyright © 2019 Heise Medien
Dank Digitalisierung sind Software und IT für die Wettbewerbsfähigkeit entscheidend. Oder ist das IT-Chauvinismus?
Viele Produkte sind mittlerweile reine Software oder Software definiert zumindest wesentliche Eigenschaften. Ein Software-Update reichte aus, um Teslas Autos mit besserem Beschleunigungsvermögen auszustatten. Fahrassistenten der Teslas werden ständig verbessert. Ein Software-Update könnte eines Tages sogar autonomes Fahren ermöglichen. Wenn solche wichtigen Features, aber auch die Fahrleistungen "nur" von Software abhängen, dann ist diese selbst für so physische Produkte wie Autos entscheidend. Wer schneller und besser Software entwickelt, wird über kurz oder lang die besseren Produkte haben und wettbewerbsfähiger sein.
Dazu kommt, dass viele Geschäftsprozesse mittlerweile durch Software umgesetzt werden. Wer also seine Geschäftsprozesse optimieren will, muss am Ende Software schreiben. Auch hier gilt: Wer die Softwareentwicklung besser beherrscht, kann Prozesse besser optimieren und so wettbewerbsfähiger werden.
Viele Softwareexperten sagen, dass die Qualität der Software und die Codequalität entscheidend für die Änderbarkeit der Software und damit den wirtschaftlichen Erfolg eines Unternehmens sind. Nach einiger Zeit in der IT-Branche beobachtet man aber, dass wirtschaftlich erfolgreiche Unternehmen oft große Herausforderungen in ihren IT-Systemen haben. Eine offensichtliche Beziehung zwischen Softwarequalität und wirtschaftlichem Erfolg scheint es nicht zu geben. Warum?
Eine mögliche Erklärung ist, dass Marktmechanismen Zeit benötigen, um zu greifen. Wer zu wenig in IT und Software investiert, der wird vom Markt gefegt, aber das kann einige Zeit dauern. Mitwettbewerber werden mit überlegener IT schneller Features ausrollen, Marktanteile gewinnen, und dann ist es zu spät. Also müssen sich Unternehmen mit einer hervorragenden IT früher oder später durchsetzen.
Wer seine IT nicht ausreichend optimiert, kann sich schon mal einen geeigneten Insolvenzverwalter suchen. Damit ist der Sieg von besserer IT und überlegenen Softwareentwicklungsansätzen wie Agilität unausweichlich. Es erscheint aber oft nicht so, als würden diese Marktmechanismen wirklich so effektiv wirken. Daher muss es auch andere Erklärungsmöglichkeiten geben.
Vielleicht ist die Wahrnehmung der IT einfach falsch. IT-Experten finden IT wichtig, weil es ihr Bereich ist. Sie beschäftigen sich tagtäglich mit ihr. Wenn IT für einen persönlich so wichtig ist, nimmt man schnell an, dass es für alle wichtig sein muss. In einem Projekt habe ich die Aussage gehört, dass man im Notfall das Unternehmen ohne Fachbereich weiterführen kann, weil die IT die Prozesse ja sowieso am besten versteht. Das war zwar scherzhaft gemeint, zeigt aber, wie wichtig sich die IT teilweise nimmt.
Wenn IT für den Geschäftserfolg nicht entscheidend ist, dann muss es andere Dinge geben, die zum Erfolg oder Misserfolg eines Unternehmens führen. Und zwar muss es sie selbst dann geben, wenn das Produkt IT-getrieben ist. Ein Beispiel ist die Finanzbranche: In ihr ist eigentlich alles nur IT und Daten. Ein Konto, ein Depot oder eine Versicherungspolice haben anders als ein Auto keine physische Ausprägung, sondern existieren nur als Teil eines IT-Systems.
Also sollte alles ganz einfach sein: Fin-Tech-Start-up gründen, ein neues IT-System aufbauen und so unbelastet von der Legacy der etablierten Konkurrenz schnell neue Features ausliefern und den Markt aufrollen. In der Finanzbranche sind aber ganz andere Faktoren entscheiden: Finanzen, Versicherungen und Banken sind Vertrauenssache. Nicht jeder vertraut einem frischen, hippen Unternehmen sein Geld an. Ich kann mir beispielsweise nicht vorstellen, dass meine Eltern jemals von der Bank, bei der sie jetzt schon viele Jahrzehnte sind, zu einer anderen Bank wechseln. Wenn ein Fin-Tech-Start-up sie als Kunden gewinnen will, muss ein etabliertes Finanzunternehmen, bei dem sie bereits Kunden sind, die Produkte für das Start-up vertreiben. Ein lange am Markt präsentes Unternehmen genießt auch bei anderen Kunden sicherlich mehr Vertrauen als ein neues Start-up.
Demnach ist IT sogar in der so virtuellen Finanzbranche nicht der alleinige Faktor für eine bessere Wettbewerbsfähigkeit. Vielleicht ist es noch nicht einmal der Wichtigste. Das sollten wir IT-Experten im Hinterkopf behalten, denn es ist nur natürlich, die eigene Tätigkeit wichtiger zu finden, als sie tatsächlich ist. Außerdem dürfen wir Investitionen in IT nicht nur mit Wettbewerbsfähigkeit begründen oder gar darauf hoffen, dass sich bessere IT wegen der Marktmechanismen von selbst durchsetzt.
Vielen Dank an meine Kollegin Anja Kammer für die Kommentare zu einer früheren Version des Artikels.
IT ist oft weniger wichtig für den Erfolg eines Unternehmens, als wir IT-Experten denken.
URL dieses Artikels:http://www.heise.de/-4494332
Copyright © 2019 Heise Medien
FreshRSS