Deine Entscheidungen als Teil eines Softwareentwicklung-Teams können die Realität formen! Aber wie ist das möglich? Ich möchte die das anhand von drei kleinen Beispielen verdeutlichen.

Beispiel 1: Geschlecht

Wenn dein System nach Geschlechtskategorien fragen muss, könnte die Anforderung lauten, nur nach „weiblich“ und „männlich“ zu fragen. Vielleicht bist du gesetzlich verpflichtet, eine dritte Option anzubieten. Selbst wenn das nicht der Fall ist, solltest du es tun. Und vielleicht wäre die Möglichkeit für „keine Angabe“ zuzulassen auch eine gute Idee. Klar, du kannst da nicht einfach aus einer Laune heraus beim Implementieren bestimmen, aber als Teil eines Entwicklungsteams bist du in der Position dem Business (ich werde „Business“ und „Kunde“ hier meist synonym verwenden) aufzeigen, dass es technisch kaum Aufwand bedeutet, mehr Geschlechtsoptionen oder eine „keine Angabe“-Option bereitzustellen. Schließlich musst du ohnehin auf verschiedene Bedingungen reagieren. Und falls nicht, kannst du das Business fragen, warum diese Information überhaupt benötigt wird. Wahrscheinlich geht es um Statistiken, Marketingkampagnen oder personalisierte Kommunikation. Sollte es nur um personalisierte Kommunikation gehen, kannst du auch vorschlagen direkt nach eine Anrede, statt des Geschlechtes zu fragen. Ja, personalisierte Kommunikation könnte bedeuten, dass zusätzliche Bedingungen für E-Mail-Vorlagen oder andere nutzerorientierte Inhalte erforderlich sind. Die Unterscheidung zwischen „weiblich“ und „männlich“ ist aber eh schon notwendig, diese Stellen zu erweitern sollte wenig Aufwand sein. Besonders, wenn von Anfang mehr als eine binäre Ausprägung vorgesehen ist, dann kann das direkt in der Modellierung und Architektur so abgebildet werden. Aber vielleicht gibt es auch eine Möglichkeit, Texte so zu formulieren, dass geschlechtsspezifische Unterschiede minimiert werden.

Was aber, wenn der Grund ein seher spezifischer ist? Vielleicht braucht das Business die Geschlechtsangabe aus einem ganz bestimmten Grund. Angenommen, es geht um die Einteilung in Sportteams, die nur „männlich“, „weiblich“ oder „gemischt“ kennen. Doch wäre das nicht ein eigener Anwendungsfall? Das könnte ein zusätzliches Datenfeld rechtfertigen, genau für diesen Fall rechtfertigen. Kein Grund also diese Konzepte zu mischen. Auch darauf kannst du hinweisen.

Ein verwandtes Problem könnten Vor- und Nachnamen sein. Dein System könnte den offiziellen Namen benötigen, der im Ausweis steht. Doch vielleicht ist dieser Name nicht mehr aktuell, weil jemand gerade eine Namensänderung durchführt. Hier könntest du ein „Rufname“-Feld hinzufügen, das – falls ausgefüllt und möglich – statt des offiziellen Vornamens verwendet wird. Das wäre von Anfang an leicht zu modellieren, später aber schwerer einzubauen.

Grundsätzlich gilt: Solange du auf eine Information nicht direkt reagieren musst (z. B. durch geschlechtsspezifische Formulierungen in Texten), ist es einfach, eine vielfältigere Realität abzubilden. Falls du auf diese Information reagieren musst, könnte es komplexer werden. Dann ist es aber umso wichtiger. Und du als Softwareentwickler:in, Softwaretester:in, Product Owner, Analyst oder auch SCRUM Master kannst diesen Gedanken äußern und so die Realität für die Nutzer mit beeinflussen.

Beispiel 2: Paar oder Familie?

Nun ein Beispiel, das mich persönlich etwas stört. Wenn meine Partnerin und ich in den Urlaub fahren, werden wir meistens als Familie erfasst. Obwohl wir in einer langfristigen Beziehung sind, teilen wir weder denselben Nachnamen noch sind wir eine Familie. Wenn wir eine Reise oder einen Hotelaufenthalt buchen, wird sehr häufig der Nachname der Person für uns beide übernommen, die sich als primärer Kontakt eingetragen hat. Das kann manchmal verwirrend sein, etwa beim Unterschreiben einer Rechnung. Es ist zwar nur eine kleine Unannehmlichkeit, aber es nervt. Vor allem, wenn wir überall unsere vollständigen Namen angeben müssen – und dann trotzdem als Familie mit einem gemeinsamen Nachnamen behandelt werden. Ein Teil in mir ist immer versucht sich die Softwaresysteme anzuschauen und grantelt ein wenig darüber wie alt und schlecht die wohl sein müssen. Bis mir dann einfällt wie schnell solche vermeintlich kleinen Probleme doch sehr komplex werden.

Darum schauen wir mal ein wenig tiefer. Nehmen wir an, wir arbeiten an einer Buchungssoftware. Diese Software erfasst eh schon die vollständigen Informationen aller Gäste. Wir sind also fein raus, richtig? Nicht, wenn wir das komplette soziotechnische System Hotel anschauen. Auf der technischen Seite können wir Bruchstellen bei der Integration anderer Systeme haben. Was, wenn das Hotelmanagementsystem pro Zimmer nur einen Nachnamen zulässt und das Abrechnungssystem auf diese Daten zugreift? Was, wenn das Hotelrestaurant auch nur einen einzelnen Nachnamen pro Tisch abbilden kann? Und wie beeinflusst dieser Bruch das Verhalten des Personals? Angestellte außerhalb des Empfangs können das vielleicht gar nicht wissen, wären aber im blödesten Fall die ersten die den eventuellen Ärger abbekommen würden.

Man könnte nun argumentieren: „Warum sich die Mühe machen? Als Entwicklerteam können wir das sowieso nicht ändern.“ Und ich stimme zu – allein können wir es nicht ändern. Aber wir können auf das Problem aufmerksam machen. Vielleicht sind wir die ersten, die diese Frage stellen. Vielleicht entscheidet sich das Business, dies als besonderes Feature zu vermarkten – beispielsweise in einem Hotelmanagementsystem. Oder es könnte zumindest in die Dokumentation aufgenommen werden. Vielleicht hat das Business darüber nachgedacht, aber die Kosten als zu hoch eingeschätzt, ohne es je als Anforderung zu formulieren und damit ein Entwicklerteam zu fragen – dann wäre es unsere Aufgabe, eine realistischere Kostenschätzung abzugeben. Vielleicht wird das Problem auch einfach ignoriert. Doch das sollte uns nicht daran hindern, solche Fragen zu stellen.

Beispiel 3: Automatische Entscheidungsysteme

Als letztes Beispiel tauchen wir noch ein wenig tiefer in Software als soziotechnisches System ein. Ich durfte vor einiger Zeit einmal eine Bachelorarbeit über automatisierte Entscheidungssysteme (ADMS) in der Sozialen Arbeit lesen. Danach konnte ich ein vages, beunruhigendes Gefühl in Worte fassen. Die Autorin analysierte in „Algorithmische Entscheidungssysteme in der Sozialen Arbeit unter kritischer Perspektive” ADMS unter dem Blickwinkel der Kritischen Theorie. Neben dieser Analyse – und für mich einer Einführung in die kritische Theorie – enthielt die Arbeit einige Beispiele.

Eines davon ging ungefähr so:

Die Kinderbetreuungsdienste sind ständig überlastet. Es wäre toll, wenn ADMS ihnen helfen könnte, die Arbeitsbelastung zu verringern. Wenn ein Kind aus einer Familie herausgenomen werden muss, werden viele Messdaten und Berichte ausgewertet. Auch Erfahrung kommt ins Spiel und fließt mit ein. Wäre es nicht großartig, diese Kennzahlen zu verwenden, sie in ein Modell einzuspeisen und eine Bewertung zu erhalten, nach der die Entscheidung getroffen werden sollte? Natürlich wird ein Mensch die endgültige Entscheidung treffen müssen, aber endlich wäre die Entscheidung Objektiv und viel effizienter!

Ich werde nicht näher auf die Verzerrungen der Datenmodelle und dergleichen eingehen. Das sind wohlbekannte und oft genug ignorierte Probleme. Und sie sind auch nicht vollständig für das beängstigende Gefühl verantwortlich, das ich habe. Außerdem ist dies etwas, das wir als Softwareentwickler:innen vielleicht nicht direkt oder erfolgreich beeinflussen können. Wir können das Problem zwar ansprechen, aber höchstwahrscheinlich wird diese Warnung ignoriert werden. Aber was können wir dann tun?

Stell dir vor, wir arbeiten daran, ein solches ADMS in eine Software für Kinderbetreuungsdienste zu integrieren. Wie werden wir die Daten präsentieren? Wie können wir die Endnutzerschnittstelle und damit den Nutzer beeinflussen? Abhängig von der Projektstruktur sind wir vielleicht ziemlich frei oder können hoffentlich zumindest unsere Ideen einbringen und werden gehört. Hier sind einige Fragen, die wir stellen könnten:

• Soll der Dienst nur die Empfehlung ohne weitere Details anzeigen? Immerhin handelt es sich um einen objektiven Wert.
• Soll die Punktzahl automatisch berechnet und als eine einzelne Zahl dargestellt werden?
• Soll die Punktzahl nur auf Anfrage berechnet werden? Dann wird der Nutzer nicht beeinflusst, wenn er sich den Fall zum ersten Mal ansieht.
• Wenn die Punktzahl auf Anfrage berechnet wird und das Ergebnis im Grunde sofort verfügbar ist, sollten wir es dann verzögern, um dem Benutzer Zeit zu geben, über die Punktzahl nachzudenken, die er aufgrund seiner Erfahrung und des Falles erwartet?
• Sollte neben dem Ergebnis eine Erklärung angezeigt werden?
• Sollte das Ergebnis nur dann angezeigt werden, wenn der Nutzer es sehen möchte, und standardmäßig ausgeblendet bleiben? Auch hier soll der Nutzer nicht direkt von der Zahl beeinflusst werden.

Diese Fragen sollte sich jedes Team stellen – selbst wenn die Anforderung explizit lautet, die Empfehlung sofort anzuzeigen. Ich persönlich würde mich für eine Lösung entscheiden, bei der sie nur auf Anfrage angezeigt wird und beim ersten Mal die Berechnung verzögert wird. Das kommt ein wenig aus persönlicher Erfahrung mit anderer Software und Prozessen. Wenn mir ein System eine einzige Zahl präsentiert, die alle anderen Kennzahlen zusammenzufassen scheint, springt mein Blick auf diese Zahl, und meine Vorurteile sind gefestigt bzw. mein Anker ist gesetzt. Damit werde ich mich nicht mehr allzu weit von dieser Einschätzung entfernen. Wenn ich mich aber bewusst entscheiden muss diesen Wert sichtbar zu machen, verlangsamt mich das und lässt mein Gehirn aufholen. Dann kann ich hinterfragen, was ich tue.

Was sollen wir tun?

Genug der Beispiele. Du fragst dich vielleicht schon, warum ein Softwareentwicklungsteam oder ein:e einzelne:r Entwickler:in solche Fragen in Betracht ziehen sollte. Vielleicht sagst du dir sogar: „Ich bin nur ein Code-Monkey und werde nur bezahlt definierte Funktionen zu implementieren. Ich habe genug technische Details, um die ich mich kümmern muss.“ Ich kenne dieses Gefühl. Und doch bin ich anderer Meinung, ich fordere dich nicht auf, einen Kampf aufzunehmen; ich bitte dich jedoch, deine Bedenken zu äußern und deine Erkenntnisse mitzuteilen. Vielleicht werden sie gehört. Vielleicht aber auch nicht. Ich persönlich schlafe besser, wenn ich sie äußere. Und doch habe ich oft genug nicht die Kraft dazu. Oder ich bin in Eile und vergesse es. Oder die Unternehmens-/Teamkultur passt nicht (das wird dann ein ganz anderes Thema).

Ich sehe auch ein Problem bei Projekten mit Festpreisen und festen Funktionen. Der Kunde hat sich bereits entschieden. Die Verträge sind abgeschlossen, und das Team kann durch Zeit- und Budgetbeschränkungen mehr oder weniger stark eingeschränkt sein. Dann bleibt keine Zeit, sich zu fragen, wie sich die Software oder das Modell auf die Realität auswirken könnte. Vielleicht gibt es nicht einmal mehr die Möglichkeit, mit dem Unternehmen zu sprechen, selbst über einfache Ideen, wie man die Realität und Abläufe besser gestalten könnte.

Vielleicht ist das ein Grund, warum ich agile Entwicklung und domain-driven-design (DDD) für gute Konzepte halte. Das eine verspricht Anpassungsfähigkeit während der Entwicklung und das andere legt Wert darauf, dass die Architektur der Fachdomäne folgt und gibt Teams so Einblick in die Verwendung eines Systems und damit auch die Möglichkeit sinnvolle und wichtige Fragen zu stellen.

Fazit

Um alles zusammenzufassen. Für mich formt Software die Realität. Für mich ist Software nicht nur eine technische, sondern eine soziotechnische Angelegenheit. Man kann ein soziales Problem nicht lösen, indem man es mit Technologie überzieht. Technologie kann helfen oder schaden. Und aus diesem Grund sehe ich jede:n, der an der Softwareentwicklung beteiligt ist, in der Verantwortung, die Realität zu gestalten. Mir ist auch wichtig hier hervorzuheben, dass es sich hier um einen Teamsport handelt. Wir brauchen vielfältige Teams, wir brauchen alle Erfahrungen, die wir bekommen können, um eine freundliche und integrative Realität zu gestalten. Wir müssen in ständigem Kontakt mit der Geschäftswelt bleiben; wir brauchen Leute, die sich im technischen Bereich gut auskennen. Vielleicht brauchen wir auch reine Code-Monkeys. Höchstwahrscheinlich werden sich die Anforderungen während des Projektverlaufs oder der Produktlebensdauer ändern.

Ich persönlich genieße es und verliere mich manchmal darin, Funktionen zu implementieren und Aufgaben abzuschließen. Das fühlt sich wie messbare Produktivität an. Aber ich habe auch Spaß daran, die Realität zu gestalten und zu versuchen, sie freundlicher zu machen, und vielleicht finde ich das sogar noch lohnender. Wie sieht das bei dir aus?

Dieser Beitrag basiert auf einem Englisch Artikel auf Martins privatem Blog veröffentlicht.