Gesetze der Softwareentwicklung II

Das erste Gesetz der Softwareentwicklung ist scheinbar trivial und doch sehr wichtig. Nach ihm können wir nur eine "gute Software", d.h. eine Software mit wartbaren Strukturen für Anforderungen entwickeln, die wir kennen. Trivial ist das, weil es sich nicht nur selbstverständlich anhört, sondern im Grunde auch ist. Wichtig ist die explizite Formulierung dieses Gesetzes aber dennoch, weil die gängige Praxis in vielen Projekten im nicht Rechnung trägt. Denn da die Softwareentwicklung quasi schon sprichwörtlich nie alle Anforderungen kennt, sind die Softwarestrukturen immer suboptimal. Suboptimale Strukturen machen die Pflege von Software schwer und schwerer, also - so sollte man denken - investieren Projekte immer wieder Zeit, um die suboptimalen Strukturen zu verbessern. Sie würden dann quasi innehalten und für die implementierten Anforderungen die Strukturen verbesseren (Refaktorisierung), bevor weitere Anforderungen erfüllt werden. Dieses Innehalten kommt jedoch nur selten, sehr selten vor. Es scheint gegenüber dem Kunden (oder dem Chef als Vertreter der Kundschaft) keinen Wert zu haben. Deshalb wird dafür nicht systematisch Zeit eingeplant. Das Resultat: Die Struktur der Software verfällt über die Zeit. Die Entropie in ihr nimmt ständig zu, die Unordnung wächst (siehe auch Gesetz 4 der Softwareentwicklung).

Aber lassen wir diese Entwicklung von Qualität für einen Moment außer acht. Nehmen wir Gesetz 1 mal einfach nur als trivial hin. Nehmen wir auch einfach mal an, wir würden alle Anforderungen für eine Software kennen. Schaffen wir es dann wirklich, eine optimale Struktur für unsere Software zu planen? Nein.

Gesetz 1 definiert die entscheidende Voraussetzung für optimale Softwarestruktur, d.h. langlebige Software. Gesetz 1 sagt, ohne die Kenntnis aller Anforderungen kommen wir zu keiner langfristig guten Struktur. Anforderungskenntnis ist aber nur eine notwendige Voraussetzung, keine hinreichende. Denn leider gilt nicht nur Gesetz 1, sondern auch...

Gesetz 2: Optimale Strukturen lassen sich nicht aus Anforderungen ableiten

Selbst also, wenn wir die Anforderungen an Funktionalität, Performance, Wartbarkeit usw. kennen, dann können wir immer noch keine optimale Struktur für die Implementation ermitteln. Dafür gibt es zwei Gründe:

a. Auch wenn wir meinen, die Anforderungen zu kennen, kennen wir sie nicht wirklich. Wir kennen sie nicht wirklich, weil entweder der Kunde sie (noch) nicht wirklich kennt; er weiß also selbst nicht, was er will bzw.  braucht. Oder der Kunde hat die ihm tatsächlich bekannten Anforderungen - natürlich unwissentlich und ungewollt - nur unvollständig mitgeteilt. Oder es gab schlicht Übermittlungsfehler, die Anforderungen sind bei uns nicht verlustfrei angekommen; wir meinen sie zu verstehen, missverstehen sie aber in Wirklichkeit. Auf die eine oder andere Weise kann es also leicht passieren, dass wir zurück bei Gesetz 1 sind: Wir kennen die wahren Anforderungen nicht, sondern nur eine Untermenge. Damit lässt sich kein optimaler Start machen.

b. Selbst wenn wir nun aber die Kundenanforderungen wirklich, wirklich kennen sollten - was selten genug der Fall ist -, dann gibt es immer noch ein Problem bei ihrer Umsetzung: unsere Tools und Technologien. Unsere Branche ist wie kaum eine andere geprägt von ständigen Neuerungen. Materalien (APIs) und Werkzeuge (IDE, Sprachen usw.) sind in ständig wachsendem Fluss. Wir haben immer weniger Zeit, sie wirklich solide zu erlernen. Das bedeutet aber, dass wir immer wieder auf unangenehme Überraschungen bei ihrem Einsatz stoßen. Sie funktionieren nicht wie angenommen. Strukturen lassen sich aber nur für Bekannte Einsatzformen von Materialien und Werkzeugen planen. Wenn wir unseren Werkzeugkasten aber immer weniger beherrschen, er ständig wächst, dann können wir für ihn und mit ihm keine optimalen Strukturen entwerfen. Beispiel: Wer meint, der neue O/R Mapper funktioniert so und so und darauf aufbauend eine Architektur plant und dann stellt sich bei der Implementation heraus, der O/R Mapper funktioniert leider nicht so... der verlässt sehr schnell die scheinbar optimale Struktur und begibt sich in den Wald der ad hoc Anpassungen. Die widersprechen aber selbstredend jeder optimalen Struktur.

Wenn Gesetz 1 trivial erscheint, dann sollte Gesetz 2 zumindest bescheiden machen. Wir sollten nie annehmen, überhaupt die triviale Anforderung von Gesetz 1 erfüllen zu können. Es gibt genügend Gründe, warum wir entgegen jeder Annahme eben doch nicht alle Anforderungen kennen. Und selbst wenn... dann beherrschen wir unsere Materialien und Werkzeuge, die sich quasi immer im Vorläufigen bewegen, nicht wirklich. Wenn wir ein Problem nicht schon 2-3 Mal mit durchaus unterschiedlichen Technologien gelöst haben, oder wenn wir neue Probleme nicht schon 2-3 Mal mit derselben Technologie gelöst haben, dann können wir überhaupt keine optimalen Strukturen planen.

Optimale Strukturen sind nur dort möglich, wo wir sichere Kenntnis haben. Wer die Problemdomäne aber nicht 100% kennt oder wer seine Werkzeuge nicht 100% kennt, der kann nur suboptimale Strukturen entwerfen. Teams, die Auftragsentwicklungen machen, kennen die immer wechselnden Problemdomänen nicht, da ist Suboptimalität gar nicht zu vermeiden. Andere Teams machen jahrelang dasselbe; sie kennen die Problemdomäne aus dem Effeff. Sie leiden dann zumindest darunter, dass sie bei wachsenden Anforderungen keine wirkliche Konstanz in den Implementierungstechnologien haben.

Gesetz 1 und Gesetz 2 machen also deutlich, dass optimale Strukturen kaum geplant werden können. Kommunikationsschwierigkeiten und ewige technologische Unerfahrenheit stehen dem allemal im Wege.

Aber was, wenn wir mal träumen? Was, wenn wir mal ganz naiv annehmen, dass wir die Anforderungen doch wirklich, wirklich kennen und auch noch die Meister unserer Technologien sind? Dann tritt Gesetz 3 in Kraft.