Software unterscheidet sich von den meisten anderen „Werkstoffen“. Sie ist unsichtbar. Die üblichen physikalischen Mess- und Visualisierungsmethoden funktionieren nicht. Man kann die Länge von Software nicht messen. Man kann sie nicht wiegen. Man kann sie nicht im Raum anordnen. Man kann ihre Statik nicht berechnen, sprich ob sie „trägt“. Man kann ihren Luftwiderstand nicht messen. Und so weiter.
All die physikalischen Mess- und Visualisierungssysteme, die wir üblicherweise verwenden, um die Zweckmäßigkeit und Qualität eines Produkts zu bewerten, fehlen uns bei Software. Wir sehen sie nicht. Wir können sie nicht anfassen.
Unfug zum Quadrat
Damit versagen unsere natürlichen Bewertungssysteme. Wir können Unfug zum Quadrat programmieren, ohne dass es irgendwer bemerkt. Wir können sinnbildlich Wolkenkratzer bauen, die auf einem Zahnstocher stehen. Wir können Flugzeuge aus Backsteinen bauen. Wir können Häuser mit Fluren von 5 cm Breite und Eingangstüren verkehrt herum auf dem Dach bauen. Wir können Autos bauen, die nur ein Rad haben – und das an der Fahrertür. Und ganz viel mehr. Würden wir solche Dinge in der physischen Welt entwickeln, würde selbst eine fachfremde Person sofort bemerken, dass das Unfug ist und nicht funktionieren kann – und zwar, bevor das Kind in den Brunnen gefallen ist, sprich bevor das Produkt gebaut und in den Betrieb überführt worden ist.
Bei Software ist das anders. Da fällt es nicht auf, wenn man so etwas baut. Aufgrund der extrem hohen „Formbarkeit“ von Software bekommt man das auch meist noch irgendwie zum Laufen. Dann stabilisiert man das Gebaute kräftig mit den virtuellen Gegenstücken zu ganz vielen Stützpfeilern und -brettern sowie Panzerband. Danach macht man die heftig knirschenden Stellen mit ganz viel WD-40 halbwegs geschmeidig, um den geschaffenen Unfug zum Quadrat doch noch betreiben zu können.
Das tut entsprechend weh, sowohl im Betrieb als auch in der Pflege und Weiterentwicklung. Je nach Unternehmenskultur werden die Leidtragenden dann als ineffizient beschimpft oder man arbeitet fleißig an noch mehr Stützpfeilern, Brettern, Panzerband und WD-40. Nur bemerkt bei alldem niemand, dass die geschaffene Lösung von Anfang an Unfug zum Quadrat war.
Das Unsichtbare sichtbar machen
Dass die mangelnde Eignung und Qualität der ursprünglich geschaffenen Lösung nicht bemerkt wird, liegt an der Unsichtbarkeit von Software. Wir sehen den Unfug schlicht nicht. Auch ein Blick in den Code hilft dabei nicht. Da ist man viel zu nah an dem Objekt der Betrachtung dran. Ich erkenne nicht, dass die Flure meines Hauses viel zu schmal sind, wenn ich 2 cm vor der Wand stehe. Aus der Entfernung erkenne ich noch nicht einmal, wenn die Haustür verkehrt herum eingebaut worden ist. Ich mag vielleicht stutzen, weil irgendetwas komisch wirkt. Aber ich vermag nicht so recht, den Finger darauf zu legen.
Wir müssen also lernen, Software aus ihrer Unsichtbarkeit herauszuziehen, um sie sinnvoll mess- und visualisierbar zu machen. Viele von Ihnen denken dabei wahrscheinlich spontan an Architekturdokumentation. In der Tat kann diese uns ein Stück weiterhelfen. Wir können Strukturen besser erfassbar machen. Wir können Eignung und Qualität der Software besser greifbar machen.
Architekturdokumentation in der heute üblichen Form ist aber immer noch keine umfassende Lösung, denn sie entbehrt immer noch eines unbestechlichen Maßsystems wie Länge oder Gewicht in der physischen Welt. Das gibt uns die Freiheit, unsere Architektur nach eigenem Belieben zu dokumentieren. So können wir die „Flure“ in unserer Software zwar darstellen. Aber die Tatsache, dass sie nur 5 cm breit und damit komplett unbrauchbar sind, wird dadurch nicht ersichtlich. Außerdem sind alle Architekturdokumentationen letztlich Modelle. Sie lassen absichtlich oder unabsichtlich Details weg. Damit kann ich die Lage meiner Eingangstür verschweigen oder auch, dass mein Flugzeug aus Backsteinen gefertigt wird. Es liegt also immer noch an der Kompetenz und dem Willen der dokumentierenden Person, ob Eignung und Qualität des Designs nachvollziehbar werden oder nicht.
Kein Fortschritt in Sicht
Nächstes Jahr wird das Essay von Fred Brooks 40 Jahre alt. Man sollte meinen, die damals beschriebenen Probleme seien schon lange gelöst. Leider sind sie es nicht. Stattdessen haben sich die damals bereits erkannten und beschriebenen Probleme nur mehr und mehr verschärft. Von daher stellt sich die Frage, ob und wann wir es schaffen, eine Art der Messbarkeit und Visualisierbarkeit von Software zu schaffen, dass auch fachfremde Personen bereits im Vorfeld erkennen können, wenn eine Lösung Unfug zum Quadrat ist, sprich schwerwiegende Mängel bezüglich Eignung und Qualität aufweist.
Bis dahin gilt wohl weiterhin in Anlehnung an das bekannte Zitat von Forrest Gump: „Software ist wie eine Schachtel Pralinen. Man weiß nie, was man kriegt.“
Uwe Friedrichsen
Herausgeber IT Spektrum
https://www.sigs.de/uebersicht-magazine/it-spektrum/architekturen-dokumentieren-und-bewerten/
