In der Welt der Softwareentwicklung scheint es oft so, als ob die größten Herausforderungen nicht darin bestehen, die Standardfälle zu bearbeiten, sondern die zahlreichen unangenehmen Ausnahmen, die aus der realen Welt stammen. Dieses Phänomen wird mit dem Begriff „Edge Case Poisoning“ bezeichnet – eine Art von Komplexitätsvergiftung, die dadurch entsteht, dass eine kleine Anzahl spezieller Sonderfälle ein ansonsten einfaches Datenmodell stark verkompliziert. Um das Thema greifbar zu machen, lohnt sich ein Blick in ein für viele zunächst untypisches Umfeld: Kochrezepte und deren Modellierung in Software. Rezeptbücher umfassen gewöhnlich eine Vielzahl an Zutaten, Mengen und Anweisungen. Auf den ersten Blick scheint es einfach, Rezepte als eine Liste von Zutaten mit zugehörigen Mengenangaben darzustellen. Doch schon bei genauerem Hinsehen werden viele Ausnahmen sichtbar, die eine simple Datenstruktur in eine äußerst komplexe verwandeln.
Das Originalmodell könnte folgendermaßen aussehen: Ein Rezept besteht aus einer Liste von Zutaten, wobei jede Zutat aus einer Lebensmittelbezeichnung sowie einer Masse für die Menge besteht. So lässt sich beispielsweise ein Rezept für „Anise Sticks“ (Anisstangen) mit Zutaten wie Schlagsahne, Glukosesirup und Milchschokolade darstellen. Diese Zutaten besitzen immer eine Masseangabe, etwa Gramm oder Kilogramm – auf den ersten Blick eine klare und unkomplizierte Abbildung. Das Problem taucht aber auf, wenn andere Rezepte mit unterschiedlichen Anforderungen betrachtet werden. Beispielsweise beinhaltet „Citrus Confit“ Zitronenschalen, die nicht in Gramm angegeben werden, sondern als Stückzahl, hier in „Schalen“. Daraus folgt, dass ein Maß nicht immer eine Masse sein kann, sondern auch Mengen in Stückzahlen oder anderen Maßeinheiten akzeptiert werden müssen. Diese Erweiterung zwingt zu einer komplexeren Definition des Maßes, das nun entweder Masse oder Stückzahl sein kann.
Doch es kommt noch komplexer: Zutaten wie „Foil Cups“ (Folienbecher) stellen keine Lebensmittel dar, sondern sind in diesem Kontext Hilfsmittel oder Zubehör. Sie müssen zwar im Rezept genannt werden, dürfen aber nicht als Lebensmittel betrachtet werden, weil sie nicht essbar sind. Dadurch muss das Modell eine Trennung zwischen essbaren und nicht-essbaren Gegenständen einführen. Die Komplexität wächst weiter, wenn optionale Zutaten ins Spiel kommen. Manche Rezepte enthalten eine Liste von zwingend benötigten Zutaten und eine weitere Liste von optionalen Bestandteilen, die nach Belieben hinzugefügt werden können. Die Datenstruktur entwickelt sich von einer einfachen Liste zu einem Dictionary oder Objekt mit zwei Listen – erforderlichen und optionalen Zutaten. Ein besonderes Edge Case tritt bei Zutaten auf, die alternativ verwendet werden können, etwa „Dried Pear or Apricot“ (getrocknete Birne oder Aprikose), von denen mindestens eine gewählt werden muss.
Dies stellt eine logische Verknüpfung zwischen Zutaten dar, die nicht durch einfache Listen abgebildet werden kann und den Einsatz von ODER-Konstruktionen oder logischen Disjunktionen erfordert. Solche logischen Formeln in Datenstrukturen bringen eine neue Ebene der Komplexität mit sich. Ein weiteres Problemfeld sind sogenannte Subrezepte. Einige Rezepte bestehen aus mehreren eigenständigen Teilrezepten, die separat zubereitet und dann kombiniert werden. Die Modellierung muss somit hierarchische Strukturen mit verschachtelten Rezeptlisten unterstützen. Auch die Möglichkeit, dass eine Zutat selbst ein vollständiges Rezept sein kann, führt zu rekursiven Datenmodellen. Rekursion wiederum birgt das Risiko von Zyklen, etwa wenn ein Rezept wie „Fondant“ sich selbst als Zutat beinhaltet. Ohne sorgfältige Erkennung und Vermeidung solcher Zyklen kann das automatische Ausrollen oder Expandieren der Rezepte zu Endlosschleifen und Abstürzen führen.
Diese zahlreichen und vielfältigen Ausnahmen zeigen exemplarisch, wie schwierig es ist, ein Datenmodell zu entwickeln, das einerseits flexibel und vollständig ist und andererseits verständlich und wartbar bleibt. Die „Happy Path“-Modelle, die nur das einfache Szenario abbilden, sind für die Mehrheit der Fälle ausreichend und leichter zu verstehen. Allerdings zerstören einzelne seltene Edge Cases die Eleganz dieses Modells und zwingen zur Einführung vielschichtiger Spezialfälle. Das führt zur sogenannten Kantenfallvergiftung, bei der die Existenz einiger weniger komplexer Ausnahmefälle das gesamte Datenmodell und die zugehörige API so weit aufblasen, dass der Code für Entwickler schwer nachvollziehbar wird.
Wer nun eine Methode schreiben möchte, um beispielsweise zu überprüfen, ob eine bestimmte Zutat in einem Rezept vorkommt, sieht sich plötzlich mit einer anspruchsvolleren Logik konfrontiert, die optionale Zutaten, alternative Zutaten und Subrezepte berücksichtigt und vielleicht noch rekursive Abfragen enthalten muss. Die Frage ist, wie kann ein Team mit Edge Case Poisoning umgehen? Eine gängige Herangehensweise ist es, den Abstraktionsgrad zu erhöhen und ein möglichst generisches Modell zu entwickeln, das alle Spezialfälle elegant abbildet. Doch das geht oft zu Lasten der Klarheit und erschwert gerade Neueinsteigern, das Gesamtsystem zu erfassen. Eine andere Strategie ist, die Anzahl der spezialisierten Fälle herunterzuschrauben, indem man viele Ausnahmen nicht formal im Datenmodell abbildet, sondern als freie Textfelder oder weniger strukturierte Daten behandelt.
Das reduziert die Komplexität des Modells, verschiebt die Verantwortung aber auf eine höhere Ebene, etwa durch eine stärkere dokumentarische oder manuelle Interpretation. Interessant ist auch der Ansatz, zwei verschiedene Modelle anzubieten: Ein einfaches „Normales Rezept“ für die 90 % der Fälle ohne Edge Cases und ein komplexes „Sonderfall-Rezept“ für die restlichen 10 %. So kann man die alltäglichen Anforderungen mit einem überschaubaren Modell bedienen und zugleich Flexibilität für Ausnahmen gewährleisten. Allerdings führt dies zu doppeltem Code und erhöhtem Wartungsaufwand. Insgesamt zeigt die Rezept-Beispielanalyse, dass jegliche Software oder API, die sich mit realen Daten und Prozessen befasst, unweigerlich auf Edge Case Poisoning stoßen wird. Ob bei Zeitzonen, Logistik oder anderen Domänen – reale Welt ist voller Ausnahmen, und diese kleinen Ausnahmen fordern unvermeidbar ein komplexeres Modell, das die Kernidee oft nur schwer erkennen lässt.
Die Herausforderung für Entwickler und Architekten ist, einen Mittelweg zu finden zwischen einer übermäßig vereinfachten Welt und einem Monster aus Spezialfällen. Dabei kann es hilfreich sein, eine Basisversion für häufige, einfache Fälle zugänglich zu machen, während anspruchsvollere Spezialfälle getrennt oder modular gehandhabt werden. Wichtig ist auch, dass das Team den Unterschied zwischen „Essentieller Komplexität“ und „Unnötiger Komplexität“ klar erkennt und vermeidet, dass Mehrkomplexität ungefiltert durch Sonderfälle die gesamte Anwendung überschattet. Edge Case Poisoning stellt also keine technische Schwäche oder Schwachstelle dar, sondern eine natürliche Konsequenz der Abbildung einer vielfältigen und unvollkommenen Realität. Softwareentwicklung ist damit nicht nur ein technisches, sondern auch ein kognitives Problem: Wie vermittelt man Komplexität so, dass sie verstehbar bleibt? Wie verhindert man, dass Spezialfälle die Allgemeingültigkeit erdrücken?
Diesen Fragen müssen wir ins Auge sehen, wenn wir robuste und zugleich nutzerfreundliche Systeme gestalten wollen.
