Wicked Features: Warum die Arbeit in großen Tech-Unternehmen so herausfordernd ist

Die Entwicklung von Software in großen Technologieunternehmen stellt oftmals eine enorm komplexe Herausforderung dar. Häufig hören Ingenieure und Entwickler, dass die Arbeit in solchen Unternehmen besonders schwer sei. Doch worin genau liegen die Gründe für diese Schwierigkeit? Ein wesentlicher Faktor sind sogenannte "wicked features" – Merkmale oder Anforderungen an die Software, die immer und bei jeder neuen Funktion bedacht werden müssen. Diese besonderen Eigenschaften dominieren die gesamte Produktentwicklung und sorgen für eine vielschichtige Komplexität, die weit über die Implementierung einzelner Funktionen hinausgeht. Um zu verstehen, was "wicked features" ausmacht, lohnt sich zunächst ein Vergleich: Wenn ein Entwickler an einer ToDo-App arbeitet und beispielsweise die Möglichkeit hinzufügt, Bilder an Aufgaben anzuhängen, handelt es sich zwar um eine bedeutende neue Funktion, doch diese Änderung betrifft nicht alle anderen Bereiche der App grundlegend.

Anders verhält es sich, wenn die ToDo-App als Webanwendung und gleichzeitig als eigenständige ausführbare Anwendung bereitgestellt werden soll. Diese Anforderung verändert die gesamte Architektur, die Entwicklungsprozesse sowie die Kompatibilität aller weiteren Features. Der entscheidende Unterschied liegt darin, dass bei "wicked features" jede neue Funktion im Kontext dieser besonderen Anforderungen entwickelt werden muss. Sie durchziehen sozusagen sämtliche Ebenen des Projekts. Typische Beispiele für solche "wicked features" sind das Hinzufügen neuer Benutzerrollen, die Entwicklung einer On-Premise-Version einer SaaS-Anwendung, das Sharding von Kundendaten auf verschiedene Datenbanken sowie die Unterstützung starker Datenlokalität.

Auch die Fähigkeit, Kundendaten zwischen Regionen zu verschieben, oder die Internationalisierung durch Übersetzung der Benutzeroberfläche gehören dazu. All diese Anforderungen wirken sich nicht punktuell, sondern dauerhaft auf die gesamte Produktentwicklung aus und müssen bei jeder neuen Funktion berücksichtigt werden. Stellt man sich vor, eine neue Funktion wie das Anhängen von Bildern wird eingeführt, stellen sich sofort komplexe Fragen: Welche Benutzerrolle darf diese Option nutzen? Wo werden die Bilder gespeichert, wenn der Kunde eine On-Premise-Lösung verwendet, also die Daten nicht in der Cloud, beispielsweise bei AWS S3, ablegt? Wie funktionieren diese Prozesse im Fall verteilter Datenbanken und Regionen? Werden entsprechende Speicherplätze in allen relevanten Umgebungen bereitgestellt? Falls der Kunde die Daten von einer Region in eine andere verschiebt, zieht das auch eine entsprechende Migration der Bilddaten nach sich? Darüber hinaus müssen alle Benutzerschnittstellentexte für die neue Funktion übersetzt werden, was zusätzliche Zeit und Koordination erfordert. Die besondere Schwierigkeit bei "wicked features" entsteht durch ihre ineinander greifende Natur. Sie ähneln einem komplexen Spiel, das auch als "Password Game" beschrieben wird.

Dabei verlangt das Spiel nach passwortbezogenen Regeln, die nicht einzeln, sondern nur gemeinsam gelöst werden können. Wenn sich eine Regel ändert, kann das all jene Passwörter ungültig machen, die zuvor alle Regeln erfüllt haben. Im Kontext der Softwareentwicklung bedeutet das, dass eine Anpassung an einer Stelle schnell zu Problemen oder Fehlern an vielen anderen Stellen führen kann. Im Gegensatz zum Passwortspiel zeigt die Software die Probleme nicht unmittelbar an. Oft erfährt man erst durch Anwendertickets, Supportanfragen oder kritische Fehlermeldungen von den Schwierigkeiten.

Viele Entwickler unterschätzen die Komplexität von Aufgaben, die durch "wicked features" verursacht werden. Neue Kolleginnen und Kollegen, die noch wenig Erfahrung im Unternehmen haben, kennen häufig nicht alle diese tiefgreifenden Anforderungen. Sie werden dann mit Fragen überrascht, die komplexe Querschnittsprobleme betreffen und merken erst spät, wie sehr die neuen Features in das bestehende System eingreifen müssen. Die sogenannten "Company Veterans", also erfahrene Mitarbeiter, sind deshalb besonders wertvoll. Ihre langjährige Erfahrung und ihr detailliertes Wissen über alle „wicked features“ machen sie zu wichtigen Ansprechpartnern und Helfern, um Probleme frühzeitig zu erkennen und zu lösen.

Es stellt sich die Frage, ob "wicked features" nicht einfach ein Designproblem sind. Könnte man nicht durch bessere Programmstruktur und Planung die Aufgaben so gestalten, dass diese schweren, übergreifenden Abhängigkeiten vermieden werden? Sicherlich ist es teilweise möglich, technische Lösungen so zu entwickeln, dass Anforderungen flexibler und weniger verbindlich in alle Funktionen eingreifen. Allerdings sind viele der Anforderungen auf einer fundamentalen Ebene notwendig. Zum Beispiel kann die Forderung, eine Softwarelösung sowohl als Cloud-SaaS als auch lokal im eigenen Rechenzentrum eines Kunden auszuführen, trotz sorgfältiger Planung nicht vollständig entkoppelt werden. Die Laufzeitumgebung, der Build-Prozess und die Architektur müssen stets darauf ausgelegt sein, was sich auf alle Erweiterungen und Änderungen auswirkt.

Ein weiteres Beispiel betrifft das Einführen neuer Benutzerrollen mit spezifischen Zugriffsrechten. Selbst wenn die Software so entworfen ist, dass Benutzerberechtigungen sauber abstrahiert und verwaltet werden, bleibt die Tatsache bestehen, dass bei jeder neuen Funktion gefragt wird, ob sie für die einzelnen Benutzerrollen zugelassen ist oder nicht. Diese Entscheidung spiegelt die grundlegende Modellierung des Systems wider und ist deshalb ebenfalls eine „wicked feature“. Es geht dabei oft weniger um Codeoptimierung, sondern vielmehr um die Grundlagen der Benutzerkinetik. Weshalb aber werden "wicked features" überhaupt implementiert, wenn sie doch die Entwicklung so sehr erschweren? Die Antwort liegt hauptsächlich in den wirtschaftlichen Interessen der Unternehmen.

Viele dieser komplexen Anforderungen gehen auf die Wünsche und Bedürfnisse von Großkunden oder Unternehmen mit hohen Ansprüchen zurück. On-Premise-Lösungen sind zum Beispiel oftmals sehr lukrativ, da sie an größere Firmen verkauft werden, die bereit sind, höhere Preise für Hochsicherheits- und Kontrollanforderungen zu zahlen. Ebenso sind Themen wie Datenlokalität und Daten-Sharding für Kunden wichtig, die großen Wert auf Performance, Datenschutz und Ausfallsicherheit legen. Auf der anderen Seite gibt es auch "wicked features", die durch Überdesign, persönlichen Ehrgeiz oder unrealistische Vorstellungen von Softwarearchitektur entstehen. Manche Entwickler bauen beispielsweise bereits sehr früh komplexe Sharding-Mechanismen ein, obwohl das Unternehmen nur wenige Anwender hat.

Oder sie extrahieren unabhängig von der Nutzeranzahl sämtliche Texte für mehrsprachige Unterstützung – obwohl die Anwendung erst einmal nur für eine Sprache vorgesehen ist. Diese Vorgehensweisen führen dazu, dass das System unnötig schwierig und schwer wartbar wird, ohne dass ein echter Vorteil entsteht. Im Alltag von Entwicklern in großen Tech-Unternehmen ist es deshalb von immensem Wert, nicht nur die technischen Fähigkeiten zu besitzen, sondern auch Erfahrung im Umgang mit "wicked features". Eine zentrale Rolle spielt es, zu verhindern, dass unnötige "wicked features" entstehen, die nur den Entwicklungsprozess erschweren. Wenn sie dennoch unvermeidbar sind, muss man die Architektur so gestalten, dass sich die Komplexität nicht über alle Bereiche verteilt, sondern möglichst isoliert bleibt.

Die Kunst liegt darin, den Einfluss dieser querschnittlichen Anforderungen einzudämmen und die künftige Arbeit für weitere Entwickler weniger belastend zu machen. Abschließend lässt sich sagen, dass "wicked features" einer der Hauptgründe sind, warum die Arbeit in großen Technologieunternehmen so herausfordernd sein kann. Sie verlangen von Entwicklern neben technischem Know-how vor allem ein gutes Verständnis der Gesamtarchitektur, ausgeprägte Kommunikationsfähigkeiten und viel Erfahrung mit den spezifischen Anforderungen ihres Arbeitgebers. Ohne diese Fähigkeiten droht, dass jede neue Änderung zu einem Dominoeffekt wird, der nicht nur den Zeitplan, sondern auch die Qualität der Software und die Motivation des Teams belastet. Die Schwierigkeiten, die "wicked features" verursachen, erklären auch, warum selbst sehr kompetente Ingenieure nach einem Wechsel zu großen Tech-Unternehmen Schwierigkeiten haben, schnell produktiv zu werden.

Sie sehen sich mit einem komplexen Geflecht von Anforderungen und Abhängigkeiten konfrontiert, die sie erst einmal verstehen und beherrschen müssen. Das Verständnis und der Umgang mit "wicked features" ist einer der Schlüsselfaktoren dafür, ob ein Entwickler in großen Tech-Firmen erfolgreich und zufrieden arbeiten kann oder nicht.