Source Reflection #3: Über spekulierende Softwareentwickler
Softwaresysteme verändern die Welt – den Satz konnte man in den letzten Jahrzehnten wohl schon so oft hören oder lesen, dass er fast trivial erscheint. Aber über seine Konsequenzen denkt man nur selten nach.
- Jörg Friedrich
Softwaresysteme verändern die Welt – den Satz konnte man in den letzten Jahrzehnten wohl schon so oft hören oder lesen, dass er fast trivial erscheint. Aber über seine Konsequenzen denkt man nur selten nach. Schon beim Benutzen der Software ist die Welt anders als zum Zeitpunkt, zu dem das Programm geschrieben wurde, und auch anders, als die Idee zum zukünftigen System entstand und seine Architektur sowie seine Benutzeroberflächen entworfen wurden.
Jede Entscheidung während des Entwurfs und der Programmierung einer Software ist eine Spekulation über die Zukunft. Denn wirklich wissen kann man das, was in Zukunft passiert, nicht. Das betrifft weniger die äußeren Umstände, die beim Einsatz der Entwicklung eintreten (obwohl auch gesetzliche Änderungen und Ähnliches für die Nutzungsmöglichkeiten des Systems relevant sein können). Ungewiss ist vielmehr, was die Menschen vor den Bildschirmen und Tastaturen wirklich mit der Software machen.
Source Reflection – die Kolumne
"Was tun wir hier eigentlich?" – Das wird sich schon mancher im Softwareprojekt gefragt haben. Wer so fragt, wird schnell philosophisch und kommt ins Staunen über das Selbstverständliche. Dieses Reflektieren macht Software nicht auf die Schnelle besser, aber auf lange Sicht ändert es die Art, wie man Problemen begegnet, und darum geht es in dieser Kolumne.
Softwareentwickler sind Spekulanten. Sie setzen darauf, dass ihre Vermutungen über das Verhalten anderer Leute richtig sind, und tun so, als ob sie über die Zukunft wüssten, was doch von unzähligen Unwägbarkeiten abhängt. Vor allem eben davon, was die Benutzer wirklich tun. Bei Standardsoftware, von der Textverarbeitung über das Blog-System bis zum Social-Media-Portal, ist das noch relativ unproblematisch, weil es zumeist eine ganze Menge Anbieter gibt. Von denen werden zwei oder drei auch weitgehend richtig spekulieren, die dann den Markt dominieren. Außerdem sind in solchen Fällen die Programmierer und Designer auch gleichzeitig Benutzer, und während sie entwickeln, können sie auch ausprobieren, was da entsteht, und sich dabei selbst beobachten.
Online-Plattformen mit vielen Nutzern und kurzen Releasezyklen haben ausgefeilte Verfahren entwickelt, um herauszufinden, ob ihre Spekulationen über das, was den Nutzern gefällt, was sie brauchen, und über die Art, wie sie es benutzen, richtig ist. Gegebenenfalls können sie schnell darauf reagieren, wenn vermeintlich spannende Features ignoriert oder geschmäht werden.
Individuelle Anforderungen
Anstrengender wird es beim Entwickeln von Individualsystemen. Oft wissen Designer und Entwickler nicht viel über den Arbeitsalltag der zukünftigen Nutzer. Und selbst wenn sie das Geschäft kennen, hilft es ihnen am Ende wenig: Denn die Software wird die Abläufe ändern, sie schafft neue Möglichkeiten und schränkt an anderen Stellen ein. Wie die Anwender damit wirklich zurechtkommen, wie sie damit (oder die Software) umgehen – all das weiß niemand, weder die Nutzer noch die Anforderungsanalysten und schon gar nicht die Programmierer.
Ein Beispiel: Eine lokale Reporting-Anwendung soll zu einer Webanwendung werden, in der alle Niederlassungen eines Unternehmens zukünftig auf einen zentral gehaltenen Datenbestand zugreifen sollen. Werden die Benutzer in den einzelnen Niederlassungen konkurrierend auf die Daten zugreifen, sodass der Application Server eine große Zahl von Berichten gleichzeitig erstellen muss? Wie lange sind die Benutzer bereit, auf einen Bericht zu warten? Wie oft rufen sie den gleichen Bericht ab? Lohnt es sich, Entwicklungskapazität in die Performance-Optimierung der Datenbankabfragen zu investieren? Wie müssen Datenbank- und Application Server dimensioniert sein? Auf diese und viele ähnliche Fragen kann niemand eine verlässliche Antwort geben, solange das System nicht produktiv genutzt wird.
Das moderne naturwissenschaftlich-technische Denken neigt dazu, die Welt für versteh-, berechen- und damit für vorhersagbar zu halten. Das gilt nicht nur für das Verhalten technischer Systeme oder physikalischer Phänomene. Ökonomieprofessoren meinen, die nächste Krise vorhersagen zu können, Politikexperten und Journalisten glauben, den Ausgang der nächsten Wahl oder den Rücktritt eines Ministers prognostizieren zu können. So entsteht die Meinung, ein technisches System wie eine Software so zu konzipieren, dass sie genau den Nutzen bringt, den man von ihr erwartet, weil sie die Anforderungen, die man zuvor ermittelt hat, eben genau erfüllt.
Man hat deshalb lange gedacht, dass eine zunehmend professionellere Anforderungsanalyse und die systematische Einbeziehung der Benutzer in den Designprozess Abhilfe schaffen könnte. Man hat mehr Ressourcen auf die Spezifikation verwendet als auf die Programmierung und sich Abstimmungs- und Genehmigungsverfahren ausgedacht. Das alles hat sicherlich einige Verbesserungen gebracht, aber nichts an der Tatsache geändert, dass all diese professionellen Prozeduren Spekulation sind, wenn auch gemeinsame Spekulation von Fachleuten und Technikern, sodass am Ende wenigstens "alle mit im Boot" saßen und keiner mehr behaupten kann, etwas schon immer gewusst zu haben und nur nie gefragt worden zu sein.
Prognosen über die Zukunft scheitern aber nicht daran, dass man irgendeine Information nicht vollständig erfasst oder nicht richtig verstanden hat. Sie werden umso unsicherer, desto mehr es auf die Handlungen von Menschen ankommt. "Woher soll ich wissen, welche Anforderungen ich an die Software haben werde, bevor ich ausprobiert habe, was ich mit ihr machen kann?" – so könnte man eine alte Psychologenweisheit auf den Softwareentwicklungsprozess anwenden.
Agile Softwareentwicklungsverfahren sollen Abhilfe schaffen, Prototypentwicklung, kurze Releasezyklen und einiges andere mehr. Die Grenzen dieser Methoden liegen nicht nur in festen Budgets, harten Terminvorgaben und mangelnder Verfügbarkeit der Fachexperten. Diese Methoden und Verfahren ändern nämlich nichts an der Tatsache, dass sich erst im wirklichen produktiven Einsatz zeigt, wie die Menschen vor den Bildschirmen mit der Software wirklich umgehen, wie sie sie handhaben, wie sie damit klarkommen und wie sie wirklich auf die Veränderungen, die das System mit sich bringt, reagieren. Das vorwegnehmen zu wollen bleibt Spekulation, denn die Menschen sind in ihren Handlungen unberechenbar.
Fazit
Ist es somit müßig, sich Gedanken darüber zu machen? Keineswegs. Notwendig ist aber vielleicht ein Umdenken: Nicht immer mehr Anforderungsdokumentation und Genehmigungsverfahren, statt dessen mehr Unsicherheitsmanagement: Wo gibt es Ungewissheit, wie sicher sind Annahmen? Welche Bandbreiten gibt es, welche Szenarien sind möglich? Und wie kann man reagieren?
Statt alles vorwegnehmen zu wollen und Entscheidungen zu erzwingen, sollten sich alle Beteiligten öfter einmal ihr Unwissen über die Zukunft eingestehen und gemeinsam überlegen, wie sie mit den Überraschungen, die die Begegnung der Benutzer mit dem System mit sich bringen wird, umgehen können. Wer weiß, dass er (über die Zukunft) fast nichts weiß, der weiß schon ziemlich viel.
Jörg Friedrich
ist Philosoph und Geschäftsführer eines Münsteraner Softwarehauses. Im vergangenen Jahr erschien sein Buch "Kritik der vernetzten Vernunft".
(ane)
