Gesetze der Softwareentwicklung I

Ja, ja, ich weiß, bei der Softwareentwicklung ist immer alles immer wieder anders. "Es kommt darauf an!" ist die Antwort auf fast jede Frage nach Einsatz einer Technologie oder eines Konzeptes. Grundsätzlich stimmt das natürlich auch. Meistens. Oft. Wie auch sonst so im Leben.

Aber es lässt sich nicht leugnen, dass wir uns alle nach Gewissheiten und Regeln sehnen. Irgendwo muss es doch mal feste Standpunkte geben, oder? Absolute Ansatzpunkte für Hebel, mit denen wir die Welt aus den Angeln heben können.

Und tatsächlich, die gibt es. Bei mehreren Beratungsterminen in der letzten Zeit sind sie mir klar geworden. Heute während eines online Unterrichts zur Einführung in den .NET Framework (ja, damit experimentiere ich; wer Interesse an einem solchen ".NET Basics Personal Training" hat, melde sich gern bei mir per Email) ist mir dann noch ein weiterer "Baustein" eingefallen, der mich nun auch veranlasst, mal darüber zu schreiben.

Also bin ich mal so kühn und behaupte, dies seien fünf grundlegende Gesetze der Softwareentwicklung:

1. Strukturen können immer nur optimal für bekannte Anforderungen sein.
2. Optimale Strukturen lassen sich nicht aus Anforderungen ableiten.
3. Optimale Strukturen werden nie verlustfrei implementiert.
4. Strukturen, die für bekannte Anforderungen aus schon existierenden weiterentwickelt werden, sind nie optimal in Bezug auf die gesamte Anforderungsmenge.
5. Anforderungen werden durch implementierte Strukturen beeinflusst.

Der Begriff "Struktur" steht in den Gesetzen sowohl für die grobe wie die feine Organisation. Er bezieht sich also sowohl auf Auswahl und Anordnung von Anweisungen, Methoden, Klassen, Komponenten, Prozessen, Dienste usw. Gemeint sind auch nicht nur Bausteine auf unterschiedlichen Abstraktionsebenen, sondern ebenfalls ihre Anordnung, d.h. wie sie in Beziehung zueinander gesetzt sind.

"Optimale Strukturen" sind dann Strukturen, die nicht nur die funktionalen und nicht-funktionalen Anforderungen erfüllen, sondern auch etwas Luft lassen für neue Anforderungen bzw. unvermeidliche Fehlerbehebungen. Optimale Strukturen sind verständlich und wartungsfreundlich, flexibel und testbar. Bei ihrem Anblick sollen Sie ausrufen "Toll! Einleuchtend! Ideal!". Optimale Strukturen haben insofern auch immer etwas von einem Kunstwerk. Sie sollen auch "schön" sein. Aber nur "auch", denn ihr Hauptzweck ist ja die Erfüllung von knallharten Anforderungen.

Aber ich möchte mich auch nicht an der Optimalität festklammern. Statt "optimal" können Sie auch "gut" oder "sehr gut" oder ein noch weniger wertendes "angemessen" lesen.

Was bedeuten nun aber suboptimale Strukturen? Ist es schlimm, wenn eine Software nur eine suboptimale Struktur hat? Suboptimal bedeutet ja nicht, dass die Software nicht funktioniert. Sie erfüllt die "platten", gut greifbaren funktionalen und nicht-funktionalen Anforderungen des Kunden. Aber: Suboptimale Strukturen machen es schwerer als nötig, Änderungen einzuarbeiten. Seien es Fehlerbehebungen, Änderungen an Features oder ganz neue Features. Änderungsfreundlichkeit aber ist - so finde ich - ein hohes Gut - auf das viele Projekte leider de facto zuwenig Wert legen. Direkt nach dem Wert von Änderungsfreundlichkeit gefragt, finden Projektteams sie zwar womöglich wichtig. Aber wenn man dann in den Code schaut, spiegelt sich diese Wertschätzung nicht wider. Sie ist - sorry to say - oft ein Lippenbekenntnis, dass man - soviel zur Entlastung der Softwareentwickler - gern in die Tat umsetzen würde, aber nicht zu können glaubt, weil "eine höhere Macht" (Kunde, Chef) das nicht zulässt.

Insofern mögen die folgenden "Gesetzeserklärungen" oder "Erklärungen der Gesetze" auch helfen, "höhere Mächte" eine andere Sicht auf Software zu vermitteln.

Gesetz 1: Optimale Strukturen für bekannte Anforderungen

Dass optimale Strukturen nur für bekannte Anforderungen ermittelt werden können, ist eigentlich kaum der Erwähnung wert. Interessant ist hingegen der Umkehrschluss: Zu unvollständigen oder schwammigen Anforderungen lassen sich keine optimalen Strukturen finden. Das bedeutet nämlich für die Softwareentwicklung, deren Projekte notorisch unterspezifiziert sind, dass ihre Strukturen quasi notwendig immer suboptimal sind.

Das Wasserfall-Vorgehensmodell hat versucht, sich dagegen zu stemmen. Es basierte auf der Annahme, Anforderungen ließen sich vollständig ermitteln. Wie die Agilitätsbewegung inzwischen ja aber hinlänglich klar gemacht haben sollte, ist das allermeistens eine Illusion. Sie können die Anforderungen an eine Software nie vollständig erheben. Anforderungen sind ständig in einem mehr oder weniger schnellen Fluss. Jedes Release Ihrer Software implementiert also nur eine vorläufige Menge von Anforderungen, einen Schnappschuss.

Dazu kommt noch, dass Projekte so groß sein können, dass die schiere Menge der Anforderungen Sie zwingt, sie in mehreren Schritten zu implementieren, die jeweils nur eine Untermenge abdecken. Selbst also bei grundsätzlich bekannten Anforderungen können Sie nicht immer all diese Anforderungen auch zur Strukturierung heranziehen. Es würde schlicht zu lange dauern, bis der Kunde ein erstes Ergebnis erhält.

Das bedeutet: Da zu einem bestimmten Zeitpunkt entweder nicht alle Anforderungen bekannt sind oder nur eine Untermenge von Anforderungen berücksichtigt werden kann, hat Software immer eine suboptimale Struktur auf das "große Ganze" bezogen:

• Wenn nicht alle Anforderungen bekannt sind, dann muss die Implementierung der bekannten Anforderungen suboptimal in Bezug auf die erst später bekannte gesamte Anforderungsmenge sein. Das gilt auch, wenn die Struktur für die implementierten Anforderungen optimal ist! Siehe dazu auch Gesetz 4.
• Wenn Sie nur eine Untermenge bekannter Anforderungen implementieren, dann mag die Struktur in Bezug auf die Untermenge optimal sein - aber nicht gleichzeitig für alle Anforderungen.

Ohne weiteren Aufwand hat Software also immer eine suboptimale Struktur. Sie ist damit weniger als möglich und nötig änderungsfreundlich. Und das wird nicht besser, wenn Sie weitere Anforderungen implementieren. Zumindest nicht, wenn Sie nicht explizit etwas dagegen tun.

Gesetz 1 beschreibt etwas Unvermeidliches: Suboptimalität. Die Qualität von Software ist immer geringer als sie sein könnte, weil wir nie alle Anforderungen im Blick haben können. Wer Software entwickelt, sollte sich also vom Gedanken der Perfektion verabschieden. Die mag sich vielleicht noch für einen Sortieralgorithmus erreichen, aber nicht mehr für eine ganze Anwendung.

Allerdings ist Gesetz 1 keine Entschuldigung für schlechte Qualität! Es macht nur klar, das wir uns nach hoher Qualität immer strecken müssen. Es gibt dabei kein Ankommen. Zwischen dem, was ist, und dem, was am besten wäre, ist immer eine Lücke. Hoffentlich wird die immer kleiner im Verlauf eines Projektes, doch schließen können Sie sie nicht.

Insgesamt hohe Qualität oder vor allem Änderungsfreundlichkeit als Grundlage für ein langes Softwareleben ergibt sich damit nicht einfach so, sondern erfordert bewussten Energieeinsatz. Akzeptieren Sie Suboptimalität, aber stemmen Sie sich gleichzeitig dagegen.

Mehr dazu im nächsten Posting.