Software kann alles – aber sollte sie auch alles dürfen?

Software kann alles. Das ist kein Werbeversprechen, das ist ein ziemlich nüchterner Sachverhalt. Wer die Zeit, die Mittel und die Motivation hat, kann mit Code fast alles abbilden, was sich denken lässt. Die spannende Frage, die mich seit Jahren beschäftigt, ist deshalb nicht, was Software kann. Sondern, was Software dürfen sollte. Ich programmiere fast jeden Tag. Neue Features. Neue Tools. Neue Integrationen. Und ich merke immer öfter, dass ich die wichtigsten Entscheidungen nicht beim Implementieren treffe, sondern beim Weglassen.

Der Moment, in dem etwas kippt

Es gibt beim Softwareentwickeln einen Moment, der selten dokumentiert ist. Eine Funktion ist fertig. Sie funktioniert. Man könnte jetzt noch die letzte Prozente extrahieren: noch ein Datenpunkt speichern, noch ein Tracking hinzufügen, noch eine kleine Abkürzung, um die User-Experience glatter zu machen. In diesem Moment kippt etwas. Die Software bleibt technisch korrekt, aber sie wird ethisch anders. Ich glaube, dass genau in diesem Moment die meisten fragwürdigen Features entstehen, die wir im Netz sehen. Nicht aus böser Absicht, sondern aus Bequemlichkeit.

Ein gutes Beispiel sind Tracking- und Analyse-Integrationen. Es ist technisch trivial, jeden Klick, jede Scroll-Tiefe und jede Pause zu erfassen. Es ist auch meistens nicht notwendig. Ich merke bei mir selbst und bei Teams, mit denen ich arbeite, wie schnell dieses „Wir sammeln mal, man weiß ja nie“ eine Normalität wird, an die man sich irgendwann nicht mehr erinnert, wenn eine Datenschutzanfrage kommt.

Warum „dürfen“ eine andere Frage ist als „können“

Das Wort „dürfen“ klingt zuerst juristisch. Ist es aber nicht nur. Im Kern steckt die Frage: Welche Konsequenz hat diese Funktion, wenn sie so funktioniert, wie ich sie jetzt baue? Für den einzelnen Nutzer. Für das Kollektiv der Nutzer. Für die Teams, die sie warten müssen. Für Menschen, die nicht hier im Raum sind, sondern irgendwo im Zweifelsfall damit leben.

Ich merke, dass sich meine Praxis in den letzten Jahren verschoben hat. Früher war mein Default: „Wir bauen das – lass uns schauen, was passiert.“ Heute ist mein Default: „Wir bauen das nicht – außer wir können klar sagen, warum es sein muss.“ Das ist ein sehr unspektakulärer Perspektivwechsel, aber er hat in der Praxis echte Wirkung. Er nimmt Daten aus Datenbanken, die dort nicht hingehören. Er nimmt Logging weg, das niemand je liest, aber im Zweifel gegen einen arbeitet. Er verhindert Features, die eigentlich nur existieren, weil der Wettbewerb sie auch hat.

Drei Leitfragen, die mir helfen

Ich benutze in Projekten drei Leitfragen, wenn eine Entscheidung kippt. Erstens: Würde ich mich selbst wohlfühlen, wenn diese Funktion auf mich angewandt wird, ohne dass man mich vorher fragt? Zweitens: Könnte ich diese Funktion einem Menschen mit wenig Technikverständnis in einem Satz erklären, und würde er das verstehen, ohne sich hinterher anders zu fühlen? Drittens: Wenn dieses Feature in einem Jahr zum Skandal wird, wie würde ich es dann erklären?

Diese Fragen sind kein Ersatz für Datenschutzrecht, Security-Review oder Team-Diskussion. Sie sind eine Art persönlicher Kompass, und ich habe gemerkt, dass sie bei 80 Prozent der Grenzfälle schon sehr gut entscheiden. Die restlichen 20 Prozent gehören sowieso in die Diskussion mit anderen Köpfen.

Verantwortung liegt bei denen, die bauen

Ich höre oft das Argument: „Wir sind nur Entwickler, die Entscheidung trifft das Business.“ Ich verstehe den Impuls, aber ich halte ihn für falsch. Der Moment, in dem man Code schreibt, ist ein Entscheidungsmoment. Die Form, die eine Funktion am Ende hat – welche Felder, welche Grenzen, welche Default-Werte – wird im Editor getroffen, nicht in der Konzernsteuerung. Das ist keine bequeme Wahrheit, aber es ist eine ehrliche.

Das gilt besonders in einer Zeit, in der KI-Systeme vieles übernehmen, was früher menschliche Abwägung war. Wenn ich einen Agenten baue, der Entscheidungen trifft, dann trage ich die Verantwortung für das Regelwerk, innerhalb dessen er das tut. Der Agent selbst trägt sie nicht. Das können wir so lange sagen, wie wir wollen.

Mein Fazit

Software darf nicht alles, nur weil sie es kann. Das klingt fast wie ein Bibelspruch, aber es ist für mich die ehrlichste Zusammenfassung dessen, was 23 Jahre Softwareentwicklung mir beigebracht haben. Die wirklich guten Produkte, mit denen ich in meinem Leben zu tun hatte, sind nicht die, die am meisten konnten. Es sind die, die an den richtigen Stellen aufgehört haben. Die gesagt haben: Hier hören wir auf, weil es sonst kippt. Hier speichern wir nicht, weil wir es nicht müssen. Hier fragen wir den Nutzer lieber, weil es ihn betrifft.

Das ist, so glaube ich, die eigentliche Kunst. Nicht mehr zu bauen, als nötig ist. Nicht weniger zu liefern, als erwartet. Und den Unterschied jeden Tag neu zu verhandeln.