The Mythical Man-Minute: Meisterschaft in Software

Wie beeinflusst die Mikroebene der Softwareentwicklung die Makroebene?
Oder: Wie könnte Softwareproduktion preiswerter werden und bessere Qualität liefern?

Auf der Suche nach dem heiligen Gral

Software-Entwicklung ist langwierig und fehleranfällig. Oftmals dauert ein Softwareprojekt länger als vorher veranschlagt wurde – wie zum Beispiel bei dem bisher in Deutschland spektakulärsten Fall "Toll Collect". Aber auch in den USA gab es schon erhebliche finanzielle Verluste durch die schwer berechenbare Softwareproduktion. Beispielsweise in Denver, wo ca. 3,2 Milliarden Dollar Schaden entstanden, nur weil ein vollautomatisches Gepäcksystem im Flughafen fehlerhaft arbeitete und schließlich erst um 16 Monate verspätet einsatzbereit war.

Schon seit Jahren sucht man in den Software-Entwicklungsabteilungen nach der Lösung für die eine Frage: Wie kann Software-Entwicklung schneller vonstatten gehen und gleichzeitig die Qualität der Software verbessert werden? Die einen glauben, durch bessere Programmiersprachen zum Ziel zu kommen – andere meinen, dass Softwareproduktion automatisiert werden muss. Beide Fraktionen haben bisher wenig greifbare Erfolge vorzuweisen. Stattdessen hat bereits Frederick Brooks in seinem Klassiker "The Mythical Man-Month" [05] geschrieben, dass kein Patentrezept für die Beschleunigung der Software-Entwicklung existiert.

Gleichzeitig gibt es noch eine weitere Fraktion, die behauptet, dass nicht nur Software-Entwicklung schneller werden, sondern auch die Qualität des Codes verbessert werden kann. Diese Fraktion behauptet, dass durch Wiederverwendung von bereits geschriebenem Programmcode erhebliche Ersparnisse gemacht werden können [01] [02] [08]. Das Prinzip leuchtet eigentlich sofort ein: Code, der nicht noch einmal geschrieben werden muss, sondern ein zweites Mal verwendet werden kann, kostet beim zweiten Mal keine Arbeit mehr.

Wenn es jedoch so einfach wäre, dann würden es alle machen. Das ist vielleicht der Grund, warum durchgängige Wiederverwendung von Software bis heute in den meisten Entwicklungsabteilungen von Softwarefirmen mehr Wunschtraum als Realität ist. [09] [04]

Doch warum ist das so?

Mythos oder Realität?

Zunächst aber ein kleiner Abstecher in andere Bereiche der Wirtschaft. Wie werden Aufwände hier reduziert?

Autobauer, wie zum Beispiel der VW-Konzern, weisen hier den Weg. Ein Auto besteht aus Tausenden von Teilen. Längst wird nicht mehr jedes Teil für genau ein bestimmtes Automodell gefertigt. Nicht nur Motoren werden inzwischen in mehreren Automodellen gleichzeitig eingebaut. Seit einigen Jahren betreiben Autobauer eine strikte Modellpolitik, bei der immer mehr Autoteile in so vielen Autovarianten wie möglich verbaut werden. VW geht hier mit seiner Plattformstrategie besonders weit. So wird die Golf-Plattform nicht nur in verschiedenen Automodellen sondern sogar markenübergreifend genutzt. Der Golf von VW, der A3 von Audi, der Altea von SEAT und der Octavia von Skoda nutzen alle die gleichen Basiskomponenten. Auch die Passat-Plattform wird inzwischen von mehreren Automarken genutzt.

Der Grund für solche Strategien ist einfach: Bewährte Komponenten, die man nur einmal entwickeln muss, reduzieren Entwicklungsaufwände und verbessern die Qualität der daraus resultierenden Produkte. Denn was öfter genutzt wird, kann gezielter und durchgreifender von Schwachstellen befreit werden – es profitiert also auch der Kunde von dieser Vereinheitlichung.

Noch älter als die Automobilindustrie ist die Bauwirtschaft – und auch hier finden wir Wiederverwendung. Nur selten werden in der Bauwirtschaft noch einzelne Komponenten komplett neu entwickelt. Stattdessen werden fertige Türen, Fenster, Dächer oder sogar ganze Baupläne genutzt.

Selbst die so alte Bauwirtschaft entwickelt sich noch heute weiter. Die Methoden zum Hausbau werden beständig verbessert. Während man vor dreißig oder vierzig Jahren noch mit relativ kleinen Ziegeln mauern musste, werden heute in der Regel große, standardisierte Quader aufeinander geschichtet. Fertighäuser werden heute sogar aus vollkommen vorproduzierten Wänden zusammengesetzt. Alles um Zeit und Arbeitskraft zu sparen – gleichzeitig kommt diese Vorgehensweise aber auch der einheitlichen Qualität des Endproduktes zugute.

Natürlich gibt es dabei auch individuelle Häuser – aber schaut man genau hin, dann besteht diese Individualität aus vielen kleinen standardisierten Teilen, die individuell neu zusammengesetzt werden. Das macht auch Sinn, denn wem nützt es beispielsweise, wenn man die Bedienung einer Tür neu lernen muss, jedes Mal wenn man ein neues Haus betritt? Aber solche Dinge sehen wir heute immer noch oft im Softwarebereich, wo gleiche Abläufe oftmals in vollkommen unterschiedlicher Weise für den Benutzer ausgestaltet sind.

Der Teufel im Detail

Wiederverwendung von einmal entwickelten Dingen kann sich also lohnen – das zeigen diese Beispiele aus anderen Bereichen eindrücklich. Doch warum hinkt hier der Softwarebereich so weit hinterher?

Wenn man heute versucht, Software wiederzuverwenden stößt man auf viele Probleme:

Viele Entwicklungsabteilungen, die es mit Wiederverwendung von Software probiert haben, sehen sich mit diesen und weiteren Problemen konfrontiert und werfen irgendwann das Handtuch, weil Wiederverwendung von Software nicht zu funktionieren scheint.

Nur wer im Kleinen treu ist ...

Dabei funktioniert sie. Viele Entwickler haben die Erfahrung gemacht, dass sie selbst entwickelte Funktionen oder ganze Programm-Bibliotheken immer wieder verwenden und dadurch sehr viel Zeit sparen können. Auch die bekannte C-Runtime-Bibliothek, welche nicht unerheblich für den Erfolg der Programmiersprache C war, ist letztendlich ein gutes Beispiel für praktizierte Wiederverwendung. Probleme, die jeder Entwickler hat, wie zum Beispiel das Kopieren einer Zeichenkette, werden ein und für alle Mal befriedigend gelöst und können von unzähligen Programmen genutzt werden.

Viele Entwickler begreifen, dass die Lösung eines Problems im Idealfall nur an einer Stelle stattfinden sollte. Deshalb ist auch eine der Grundprinzipien bei dem sogenannten "Extreme Programming" [06]: "Once and only Once" (Einmal und wirklich nur einmal). Die Entdecker dieser Entwicklungsmethode haben hier einfach begriffen, dass das Wissen, das zur Lösung eines Teilproblems notwendig ist, möglichst nur an einer Stelle im Programm fokussiert sein sollte – wenn das Problem sich ändert, muss man dann auch nur eine Stelle ändern.

Die Praxis in der Software-Entwicklung ist leider häufig anders: Probleme – auch die kleinsten – werden immer und immer wieder neu gelöst. Teilweise von verschiedenen Programmierern, oft aber auch von dem gleichen Programmierer, weil das Bewusstsein für dieses grundlegende Konzept fehlt.

Dabei könnten hier simple Grundkenntnisse aus der Datenbanktheorie durchaus helfen. Eine der Grundprinzipien in relationalen Datenbanken ist, dass gleiche Informationen nur einmal in der Datenbank abgelegt werden sollen, weil es ansonsten bei einer Änderung dieser Information zu Inkonsistenzen kommen kann. Weiterhin lässt sich auf diese Art tendenziell Speicherplatz sparen. Man spricht bei diesem Vorgehen, Doppeltspeicherungen und andere Anomalien zu vermeiden, auch von "Normalisierung".

Genau das gleiche Prinzip wenden Software-Profis auch bei der Programmierung an. Sie "normalisieren" ihre Programme so, dass der Änderungsaufwand bei Änderungen der Problemstellung minimal ist. Beim "Extreme Programming" spricht man in diesem Zusammenhang auch von "Refactoring". Was aber in Wirklichkeit geschieht, ist eine eingeschränkte Form der Wiederverwendung. Anstatt das Rad an vielen Stellen neu zu erfinden, wird es an einer Stelle richtig erfunden und dieses Rad wird immer wieder verwendet und dadurch sogar kontinuierlich immer besser.

... wird es auch im Großen sein

Was so gut in der Mikroebene klappen kann, wenn der richtige Entwickler vor dem Programmcode sitzt, könnte auch auf der Makroebene funktionieren.

Wenn man alle kleinen Teilkomponenten so baut, dass ein Problem genau an einer Stelle im Code und dadurch im ganzen Programm immer auf die gleiche Weise gelöst wird, dann ist es auch möglich, größere Komponenten in gleicher Art zusammenzubauen. Wie in der Natur: die ganze Welt ist aus einer kleinen Anzahl subatomarer Teilchen zusammengebaut, die wiederum eine überschaubare Zahl von verschiedenen Atomen bilden und aus denen sich wiederum Zellen bilden, die sich zu komplexen Gebilden wie Pflanzen, Tieren und Menschen organisieren. Genauso kann sich Software aus den kleinsten Bestandteilen über immer größer werdende Komponenten zusammensetzen.

In der Tat ist das schon heute so – letztlich besteht unsere Software nur aus Bits und Bytes, also sehr wenigen primitiven Elementen. Aber oberhalb eines gewissen Abstraktionsgrades wird die Softwarewelt plötzlich unheimlich komplex.

Was ist schiefgelaufen?

In der Natur können wir sehen, dass die selben Konstruktionsprinzipien immer wieder verwendet werden. Aber in der Software-Entwicklung? Da werden immer wieder neue Konstruktionsprinzipien angewandt und deshalb steigt die Komplexität hier so schnell an, dass schon oberhalb des Niveaus der Programmiersprache die Dinge kaum noch zusammen passen.

Wir haben es also versäumt, die mögliche Wiederverwendbarkeit auf der Mikroebene auf die Makroebene zu übertragen, weil wir nicht konsequent darauf geachtet haben, die Anzahl der Konstruktionsprinzipien (oder Konzepte) zu reduzieren beziehungsweise sie aufeinander abzustimmen.

Wenn man heute ein Programm-Modul wiederverwenden möchte, scheitert es meist schon daran, weil es sich mit einem anderen Programm-Modul nicht verträgt. Auf atomarer Ebene sind die Module zwar kompatibel, aber dann kommen so viele inkompatible Ebenen dazwischen, dass diese minimale Kompatibilität nicht weiter hilft.

Anstatt von der Basis an "Kompatibilität" und damit Wiederverwendbarkeit in unsere Software einzubauen – haben wir ein wildes Durcheinander geschaffen und hoffen verzweifelt, auf diesem Schrottplatz der Software zwei zueinander passende Teile zu finden.

Umkehr zur neuen Denkkultur

Genau das ist das Problem mit der Wiederverwendung [07]: Viele denken, dass Wiederverwendung das Finden eines passendes Teiles ist, das zufälligerweise jemand anderes schon mal implementiert hat. Dabei ist Wiederverwendbarkeit von Software der konsequente Aufbau eines Softwaresystems, bei dem wie bei den guten alten Fischertechnik-Baukästen alle Teile perfekt ineinander passen, weil sie mit sehr viel Kreativität und Einsatz aufeinander abgestimmt wurden.

Niemand würde auf die Idee kommen, seinem Kind einen Baukasten zu schenken, der einen Teil aus einem Fischertechnik-Baukasten, einen Legobaustein und viele andere Bausteine von jeweils anderen Herstellern enthält. Jedem ist klar, dass das nur zu Frustrationen führen würde. Doch in der Software-Industrie denken wir anscheinend, dass es auf diese Art gehen könnte.

Die Summe der Software-Konzepte in einem Programm nennt man auch seine Software-Architektur. In der Architektur von Software liegt also der Schlüssel zur Wiederverwendung [03]. Doch wer ist heute bereit, in Software-Architektur zu investieren, die bei den Details beginnt und sich bis zur Makroebene fortsetzt? Wo sind die Software-Architekten, die in der Lage sind, Software von der Pike auf zu gestalten, dass alles reibungslos ineinander passt?

Wiederverwendung, die aus der Makrosicht "von oben" diktiert wird, ist nicht die Lösung, denn die Reibungsverluste beim Versuch, bestehende Bausteine aufeinander anzupassen, sind groß, und meist fehlt den einzelnen Entwicklern das Problembewusstsein für echte Wiederverwendbarkeit von Software.

Leider fehlt es aber auch bei Managern oftmals an dem nötigen Problembewusstsein. Nicht selten wird ein Entwickler eher nach der Anzahl Codezeilen, die er zu produzieren in der Lage ist, bewertet als nach konzeptionellen Gesichtspunkten. Wie das Programm sich dagegen in fünf Jahren verhält oder wie viel Mehraufwand es bei der Softwarewartung produziert, wird dagegen nur sehr selten realisiert.

Das Ergebnis ist oftmals, dass man sich wundert, warum das bisher so erfolgreich laufende Projekt gerade zum Schluss so ins Trudeln geriet und plötzlich so viel Zusatzaufwand entstand oder warum die Wartungsaufwände ins Unermessliche steigen. Die noch eben so moderne Software – natürlich in der neuesten Programmiersprache – entpuppt sich plötzlich als kaum noch erweiterbare Sackgasse, die enorme Resourcen verschlingt.

Aus diesen Gründen kann Wiederverwendbarkeit von Software nur da gedeihen, wo ein starkes Commitment der Führungsetage da ist und wo bei allen Mitarbeitern das Bewusstsein für die Software-Architektur geschärft wurde. Weiterhin brauchen wir Software-Architekten, die Software-Architekturen mit einheitlichen Konzepten bis ins Detail zu bauen wissen.

Doch der Trend der heutigen Zeit geht gerade in die falsche Richtung, denn anstelle von erfahrenen Software-Entwicklern suchen viele Firmen heute nach "formbaren" Jungentwicklern, die möglichst viele Überstunden machen können. Dass genau in diesen Überstunden dann die Software entsteht, welche schon bald Probleme verursachen muss, wird auf keinem Finanzchart deutlich.

Meisterschaft in der Software-Entwicklung

Dieser Artikel kann nur einen Einstieg in dieses sehr komplexe Thema "Wiederverwendbarkeit" bieten. Ich hoffe dennoch, dass dieser Artikel bei einigen Lesern einen Umdenkprozess in Gang setzen kann. Frederick Brooks hatte Recht: die "Silberkugel", also eine Art magische Technologie, die alle unsere Software-Entwicklungsprobleme für uns löst, gibt es nicht.

Stattdessen müssen wir anfangen, Software-Entwicklung im Detail ernst zu nehmen und sie von der Pike auf neu lernen. Wir müssen akzeptieren, dass wir nur das "wiederverwenden" können, was auch "wiederverwendbar" ist. Wir müssen auch verstehen, dass wir "echte" Meisterschaft in der Software-Entwicklung nur dann erreichen werden, wenn wir zuallererst wirklich meisterhaft Software zu entwickeln gelernt haben. Dabei muss diese Meisterschaft bei den kleinsten Bausteinen anfangen und sich dann bis hin zu den komplexesten Modulen fortsetzen.