Software-Qualität und die Frage der Ehre

Im gestrigen Interview mit Karl-Heinz Strassemeyer wies dieser darauf hin, dass ein Entwickler, der sich der Open-Source-Kultur verpflichtet fühlt, seinen Code erst dann aus der Hand geben möchte, wenn er „damit Ehre einlegen kann“. Strassemeyer führte weiter aus: 

Ich weiß nicht, wie man plan-getriebene industrielle Entwicklungs-Teams so organisieren kann, dass der Entwickler mit seinem Code Ehre einlegen möchte. Bei wem sollte er überhaupt Ehre einlegen wollen?

Durch diese Frage fühlte ich mich direkt angesprochen, habe ich mich doch mehrfach mit der Frage von Professionalität und Verantwortung befasst, unter anderem in diesem Blog. Auch habe ich mich wiederholt gefragt, wie die missionarisch verbreitete Idee des quelloffenen Codes zu verstehen und wirtschaftlich und sozial einzuordnen ist. Ist man so lange in einem Gebiet tätig wie ich, nämlich über 60 Jahre, dann erscheint nicht alles neu, was als neu dargestellt wird. Ich benutze daher diese Gelegenheit, um etwas ausführlicher über meine Erfahrungen mit Software zu reflektieren.

Zunächst ein Wort zur Rolle von Projektplänen in der Entwicklung. Pläne stellen eine Vereinbarung zwischen Partnern dar, wie man ein gemeinsames Ziel zu erreichen beabsichtigt. Hat man weder Partner noch Ziele braucht man auch keinen Plan. Nimmt man seine Partner ernst, bemüht man sich zuverlässig zu sein, also den Plan einzuhalten. Zeitkritisch sind nur Projekte, die eine gewisse Bedeutung haben. Mal ist der Termin nur für das Weihnachtsgeschäft kritisch, mal für den gesamten Markterfolg. Parallelität in der Entwicklung ist immer dann der Ausweg, wenn entweder die benötigte Kompetenz und Kapazität nicht an einem Ort vorhanden ist, oder wenn das anders zu erreichende Fertigstellungsdatum inakzeptabel ist. Meine eigene Entwickler-Erfahrung führte mich daher zu folgender Bewertung: Projekte, bei denen es keine Rolle spielt, wann sie fertig werden, sollte man lieber ganz sein lassen. Im Übrigen korreliert planvolles Vorgehen häufiger mit qualitativ hochwertigen Ergebnissen als umgekehrt.

Um Programmieren zu lernen, ist es sehr nützlich, sich anderer Leute Code anzusehen. Ich erinnere mich noch gut, dass ich 1956 von der Qualität und dem Stil des Codes beeindruckt war, mit dem sich George Trimble und Elmer Kubie aus Endicott, NY, im Assembler für die IBM 650 verewigt hatten. Sie waren sozusagen meine persönlichen Lehrmeister, denen ich nachstrebte. Spätere Berufseinsteiger mussten sich andere Lehrmeister suchen. Generationen von Informatikern haben Quellcode von Edsger Dijkstra, Donald Knuth und Niklas Wirth studiert und daran ihren Stil verbessert. In der IBM wurde Quellcode immer mit verklausulierten Angaben zur Person des Entwicklers versehen, vordergründig um auf die Entstehungsgeschichte schließen zu können, nicht zuletzt aber auch, um den einzelnen Entwickler in die Verantwortung zu nehmen. Es wurde dies weniger an die große Glocke gehängt als bei Porsche die Unterschrift des Meisters auf jedem Motorblock. Es war aber im Prinzip dasselbe.

Die Strategie, den Quellcode nur bedingt zur Verfügung zu stellen, kam erst nach dem ‚Software Unbundling‘ in 1969 auf. Neben dem Schutz geistigen Eigentums sahen wir vor allem große technische Vorteile darin. Statt dass der technische Außendienst für die Behebung von Fehlern im Feld einzelne Korrekturzeilen im Quellcode erhielt, die er einbinden und kompilieren musste – mit hohem Arbeitsaufwand und großer Fehleranfälligkeit – , konnten wir ganze Moduln in Objektform als Korrektur anbieten. Das erlaubte etwas, was Kunden im Falle von Software nie machen wollten, nämlich vorbeugende Wartung. Ein Modul enthielt nicht nur die geforderte Korrektur, sondern Korrekturen zu allen Fehlern, die dieses Modul betrafen. Wir mussten daher nicht mehr warten, bis jeder Kunde auf jeden Fehler gestoßen war. Damit reduzierten wir die Anzahl der berichteten Fehler erheblich. Ich kann mich an keinen VSE-Kunden erinnern, der wegen des nicht mehr verfügbaren Quellcodes unglücklich war oder gar gekündigt hätte.

Die starke Betonung quantitativer Methoden innerhalb der IBM Software Community  durch Watts Humphrey führte dazu, dass vor allem Produktivität, Entwicklungsdauer und Fehlerhäufigkeit systematisch gemessen wurden. Sie spielten auch im internen Vergleich zwischen den Labors eine Rolle. Eigentlich wäre Rentabilität ein viel besseres Maß gewesen. Es wurde jedoch nicht herangezogen, weil hier Einflüsse dazu kamen, die außerhalb der Kontrolle des Entwicklers lagen. Was ebenfalls nicht quantifiziert wurde, war die Wartbarkeit. Immer wieder kam es dazu, dass die eine oder die andere Komponente re-implementiert wurde. Entschieden wurde hier aufgrund von Expertenurteilen. Beim DOS/VS Supervisor geschah dies mehrmals. Dann wurde auch gelegentlich Kritik zwischen Labors oder zwischen einzelnen Entwicklern laut. Immer war man bemüht, dafür zu sorgen, dass der einzelne Entwickler sich hinter dem Team zurücknahm. Wichtiger als der Erfolg eines Einzelnen war der Erfolg des Teams. Vielleicht sehe ich dies aber im Rückblick bereits etwas romantisch verbrämt.

Die Qualität von Code bekam gegenüber Produktivität und Entwicklungsdauer einen veränderten Stellenwert, als in den 1980er Jahren die Software-Wiederverwendung [1] stärker thematisiert wurde. Meine Kollegen in Böblingen setzten sich IBM-intern an die Spitze dieser Bewegung. Mit den Böblinger Bausteinen wurden insgesamt etwa 80 kLOC an Moduln, Klassen oder Routinen angeboten, die alle bekannten Datenstrukturen und Basisfunktionen abdeckten. Sie wurden von über 20 Projekten benutzt. Vor jeder Entscheidung wurden sie von den Benutzern sorgfältig analysiert. Ihre Akzeptanz war ausschließlich eine Folge ihrer hohen Qualität. Sie waren gut strukturiert, gut dokumentiert und de facto fehlerfrei. Von Kollegen in der ganzen Firma wurde nicht nur die ‚deutsche Qualität‘ gerühmt, sondern auch die Kompetenz einzelner Böblinger Entwickler. Wir erhielten zwar keine Umsatzbeteiligung, aber sehr viel Lob und Ehre. Das Ansehen, das unsere Firma damals besaß, brachte es mit sich, dass das, was sie tat, automatisch ein hohes Maß an Aufmerksamkeit in der Fachwelt erhielt. Die Kollegen vom FZI in Karlsruhe, die an diesem Böblinger Projekt mitgearbeitet hatten, waren daher überrascht und stolz zugleich, als sie von Universitäts­kollegen in Kalifornien zu hören bekamen, dass man in der Fachwelt dieses IBM-Projekt genau verfolge. Das alles geschah noch in einer Welt, in der proprietärer Code die Norm war.

Es wird hier die generelle Frage berührt, wie man technischen Leistungen die ihnen gebührende Anerkennung verschafft, vor allem aber, wer dafür verantwortlich ist. Meines Erachtens ist hier zu allererst die eigene Organisation gefordert, unterstützt durch den Feedback der eigenen Kunden. Nur die zweitbeste Lösung ist es, sich Hilfe von außerhalb der Firma zu holen. Ist die eigene Organisation nicht (mehr) fähig, ihren Technikern Anerkennung zu geben, sollte jeder professionelle Entwickler dies als Alarmzeichen ansehen, und sich schnellstens nach einem andern Wirkungsfeld umsehen. Entweder ist die Firma zu klein, schlecht geleitet, oder aber ihre Interessen liegen in einem ganz anderen Gebiet. So kann ich mir nicht vorstellen, dass die Motoren-Entwickler bei BMW, Mercedes und Porsche daran gemessen werden, was selbsternannte Juroren in Frauenzeitschriften oder Fanclubs von sich geben. Oder anders ausgedrückt: Man versucht Ehre bei dem einzulegen, dessen Anerkennung man haben möchte. Wenn die Organisation, die einen fördert und bezahlt, nicht auch die ist, bei der man Anerkennung haben will, so ist etwas faul. Offensichtlich wird nicht mehr die wertschöpfende Leistung vergütet, sondern irgendetwas anderes. Bekannte historische Beispiele sind Parteibuch oder Glaubensbekenntnis. Das mag einigen Leuten zusagen, passt aber nicht damit zusammen, wie normale Unternehmen funktionieren.

Für die Anerkennung von technischen Mitarbeitern gibt es eine Vielzahl von Möglichkeiten. Bei Unternehmen mit starker technischer Tradition findet die erfinderische Tätigkeit von Mitarbeitern eine besondere Beachtung. Man hält Ausschau nach Lösungen, die neuartig sind, da diese patentierfähig sind. Einmal geschützt, können sie wirtschaftlich sehr gut ausgenutzt werden. Dass der einzelne Erfinder seinerseits davon profitiert, ist in Deutschland sogar besser geregelt als anderswo (Stichwort: Erfindervergütung). Bei Software ist der Aspekt des Patentschutzes noch etwas unterentwickelt, ist aber – wie in diesem Blog nachgewiesen – stark im Kommen. Neben der Originalität der Lösung gibt es bei Software mehrere andere wichtige Kriterien, die für die Bewertung herangezogen werden können. Beispiele sind nutzer-relevante Funktionalität, angemessene Nutzer­schnittstelle, Robustheit gegenüber Hardware-, Software- und Nutzerfehlern, hoher Wiederverwendungswert, optimales Leistungs­verhalten und hohe Sicherheit. Schließlich mag auch die ‚Wohlgeformtheit‘ des Codes im Hinblick auf die spätere Wartbarkeit ins Gewicht fallen. Für die Entwickler ist es jedenfalls unabdingbar zu wissen, nach welchen Kriterien ihre Leistung von ihrem eigenen Management bewertet wird, und bei mehr als einem Kriterium, auch deren relative Priorität. Wie das Management diese Bewertung durchführen kann, darauf soll hier nicht weiter eingegangen werden. Bei wem die Verantwortung liegt, bedarf im Allgemeinen keiner Erklärung.

Die letzte Bemerkung, die ich machen möchte, bezieht sich auf die im Zitat zum Ausdruck kommende Selbsteinschätzung von Entwicklern. Selbstkritisch zu sein, ist zweifellos etwas Gutes. Diese Einstellung zu fördern, ist wichtig. Nur sind die Fähigkeiten des Einzelnen in dieser Hinsicht recht beschränkt. Selbst einem Genie unterlaufen bei der Programmierung Fehler, die einem Außenstehender sehr viel leichter auffallen als dem Autor selbst. Ein ausgereifter Entwicklungsprozess nimmt darauf Rücksicht. Ohne den Einzelnen zu demotivieren oder aus seiner Verantwortung zu entlassen, versucht man, zusätzliche Sicherheiten einzubauen. Dazu dienen Inspektionen und unabhängiges Testen. Sie sind in der Praxis unverzichtbar. Der selbstkritische Entwickler hält deshalb seinen Code nicht über Gebühr zurück, da er weiß, dass es für das Projekt insgesamt besser ist, wenn Inspektionen und Testen nicht allzu spät einsetzen oder gar an den Rand gedrängt werden. Dass diese Fakten in der Open-Source-Welt völlig in Vergessenheit geraten sein sollen, kann ich mir nicht vorstellen.

Zusätzliche Referenz:

1. Endres,A.: Software-Wiederverwendung Ziele, Wege und Erfahrungen, Informatik-Spektrum 11,2 (1988), 85-95