Was bedeutet „Softwarequalität“? Wie wichtig ist sie? Welchen Einfluss hat die Code-Güte auf das gesamte Softwareprodukt? Der steigende Kostendruck in der IT-Industrie führt zu Konflikten, in denen Softwareentwickler oftmals arg in die Defensive geraten.
Nicolai Josuttis, ein angesehener Experte der deutschen IT-Beraterszene, gibt auf. „Crappy Code“ nannte er seine Keynote auf der ACCU-Konferenz im vergangenen Jahr. Seine Kernaussage: Ordentliches, sauberes Programmieren bilde eine aussterbende Kunst. Als alter „IT-ler“ bringe ich für seine These viel Sympathie auf. Es spielt sich auch nach meiner Beobachtung in der Tat eine unerfreuliche Entwicklung ab. Vielerorts spart man rigoros an Design und Programmierung. Das finale Ergebnis ist, in Josuttis‘ Worten, „Crappy Code“: umständlich zu wartender, fehlerhafter Quellcode, der bei solide arbeitenden Softwerkern unweigerlich zu Gewissenskonflikten führen muss.
Konflikte sind vorprogrammiert, denn Entwickler und Manager leben oft in zwei wesensfremden Welten. Abgesehen von der Kleiderordnung und den grundverschiedenen Gesprächsthemen in der Kaffeeküche unterscheiden sie sich häufig auch im Verständnis der Zielsetzung eines Softwareprojekts. Dass „Qualität“ geliefert werden soll, darin sind sich zwar alle Beteiligten schnell einig – doch worin manifestiert sie sich eigentlich? Für den Projektleiter zählt die Erfüllung der ausformulierten Kundenanforderungen. Die Abnahmeerklärung des Kunden krönt also das Projekt. Für den Kunden sind zusätzlich Attribute wie langfristige Stabilität und Wartungsfreundlichkeit des Systems wichtig. Darin drückt sich einfach zu formulierende, leicht messbare Qualität aus. Dagegen ist die für den Entwickler so wichtige Code-Qualität nur technisch versierten Insidern zugänglich. Dies bildet, in aller Kürze, den Ursprung vieler Konflikte zwischen Technik und Management.
Als ich in jungen Jahren die ersten Assembler-Zeilen auf meinem 1982er ZX81 schrieb (mit satten 64 KB Speicher und einem Thermodrucker!), lernte ich eines schnell: Für die Qualität des Endergebnisses zählt nicht nur der bloße, funktional korrekt ausführbare Output, sondern auch die Art (um nicht zu sagen: Kunst) der Programmierung. Vergleichbare Programme einiger meiner Freunde – die zum Teil noch heute Softwaretechnik unterrichten – waren kürzer, eleganter und performanter als meine eigenen (die man heute wohl „Hacks“ nennen würde). Ich lernte, wie wichtig ein gründliches Detailwissen über die zu programmierende Maschine und das Betriebssystem ist. Es wurde mir aber auch klar, dass es eine kausale Beziehung gibt zwischen dem detailverliebten, Design-gestützten Stolz des Entwicklers und der durch den Endnutzer erfahrbaren Qualität des Endprodukts. Trotz der vorherrschenden Tendenz der letzten Jahrzehnte, Softwareentwicklung als Fließbandarbeit zu interpretieren und – analog dazu – erhebliche Effizienzsteigerungen zu erzielen, ist und bleibt der Softwareentwickler ein hochqualifizierter Handwerker, der seine Kreativität, seinen Fleiß und sein Berufsethos jeden Tag aufs Neue auf die Probe stellen muss und will.
Der handwerkliche Stolz erklärt die Emotionalität, mit der ein professioneller Entwickler die Code-Qualität ansieht. Da sind Details wie die Benennung von Variablen, verständliche Kommentare (oder gar „selbstkommentierender“ Code) und die Vermeidung von „Spaghetti“-Code genauso wichtig wie die saubere Anwendung von Entwurfsmustern und eine stabile, erweiterbare, auf modernen Paradigmen basierende Architektur. Guter Code ist „schöner“ Code. Doch was hat das mit der Qualität des Endprodukts zu tun?
Da Schönheit im Auge des Betrachters entsteht, ist diese Frage nicht einfach zu beantworten. Ich kenne keine Untersuchung, die belegen würde, dass schöner Code zu besseren (stabilen, Kunden-orientierten, wartungsfreundlicheren etc.) Produkten führt. Ich bin jedoch überzeugt, dass auch die subjektive Schönheit für die Gesamtqualität des Endprodukts eminente Bedeutung besitzt. Dieser Gedanke fußt nicht nur auf der Intuition eines alten Softwerkers. Er resultiert vielmehr aus der praktischen Beobachtung, dass ein Entwickler, der seinen Code nicht „liebt“, seine Berufung womöglich verfehlt hat. Eine positive, emotionale Beziehung der Mitarbeiter zu ihren Aufgaben wird von unzähligen Managementgurus und einem Heer von Arbeitswissenschaftlern rund um den Globus als entscheidender Wettbewerbsvorteil erfolgreicher Unternehmen angepriesen. Ich sehe keinen Grund, diese These infrage zu stellen. Ein leidenschaftlicher Entwickler agiert um Längen effizienter und effektiver als einer, der sich unmotiviert durch seinen Arbeitstag quält.
Daraus folgt, dass sogar unter der Annahme, schöner Code hätte an und für sich nichts mit der Produktqualität zu tun, das Endergebnis direkt mit der Code-Ästhetik korreliert. Denn das Bestreben der Softwareentwickler, einen schönen Code zu produzieren, rechtfertigt die Erwartung, dass sie ein hochwertiges Produkt abliefern werden.
Wie steht es vor diesem Hintergrund um die Richtigkeit der „Crappy Code“-These? Unbestritten: Es wird industrieweit viel schlechter („hässlicher“) Code produziert. Ich bin aber nicht der Meinung, dass wir die gesamte Softwareindustrie in Sippenhaft nehmen dürfen, denn nicht überall herrschen die gleichen Rahmenbedingungen. In einem Desktop-Produkt oder einer unternehmenseigenen ERP- oder CRM-Entwicklung kann man sich naturgemäß mehr Qualitätstoleranz leisten als in der Rüstungs- und Luftfahrtindustrie, wo schlechte Code-Qualität Menschenleben kosten kann. Standards wie CMMI oder SPICE schreiben Maßnahmen zur Sicherung der Design- und Code-Qualität vor. Es sind die nicht-funktionalen Anforderungen, die auf diese Art flankiert werden müssen: Performance, Stabilität, Pflegeleichtigkeit, sprich: die von Nicolai Josuttis – und vielen anderen Zeitgenossen der Beraterzunft – so vehement postulierte Nachhaltigkeit.
Interessanterweise zeigen sich gerade die Organisationen, die missionskritische Systeme entwickeln, auch an der Prozessqualität interessiert. Aus der vielbeschworenen Softwarekrise der 60er- und 70er-Jahre haben wir gelernt, dass die allseits gefürchtete Komplexität nicht nur im Quellcode lauert. Sie ist vielmehr längst auch ein verfahrenstechnisches Phänomen geworden. Großprojekte scheitern seltener an schlechter Quellcode-Qualität als an der ausufernden Komplexität der Arbeitsabläufe, einer ungeeigneten Kommunikationsstrategie und den daraus resultierenden, schwer beherrschbaren Risiken. Es ist klar geworden, dass die Code-Qualität nicht in einem luftleeren Raum entstehen kann; Sie muss in einen geeigneten Prozess eingebettet sein.
Kostet diese Qualitätssicherung Geld? Natürlich. Sollte das Controlling an der Code-Qualität sparen? Als Entwickler sage ich: auf keinen Fall! Als Manager meine ich jedoch: Das hängt vom Projektziel ab. Wir müssen uns mit dem Diktat der ökonomischen Realität arrangieren. Softwareentwicklung ist nun einmal keine Kunst – Softwareentwicklung ist Handwerk. Wir sollten uns endlich von der Vorstellung verabschieden, Software sei ein Selbstzweck und der Entwickler ein Künstler (ich erinnere mich noch an meine frühen Entwicklerjahre, als ein Kunde mich beinahe verprügelte, als ich betonte, Softwareentwicklung sei eine Kunst – Künstler werden in der Wirtschaft anscheinend wenig geschätzt). Die Erwartungshaltung ambitionierter Entwickler an ihren Beruf sollte unbedingt einem Reality Check unterzogen werden. Folgende Thesen helfen dabei:
SIEBEN THESEN FÜR PRAGMATISCHE SOFTWAREENTWICKLUNG
- Software ist ein Mittel zum Zweck.
- Laufzeitstabilität ist wichtiger als Code-Qualität.
- Produktqualität ist wichtiger als Laufzeitstabilität.
- Kundenzufriedenheit ist wichtiger als objektive Produktqualität.
- Kunden sind wichtiger als Entwickler.
- Entwickler sind wichtiger als IT-Projektmanager.
- IT-Projektmanager sind wichtiger als Projektcontroller.
Es wird immer Projekte geben, die sich kurzfristige Ziele setzen, wodurch die Qualität dem Controlling leicht zum Opfer fällt. Für Entwickler, die ihren Code lieben und ihn schön, performant und nachhaltig gestalten möchten, wird sich jedoch immer das richtige Projektumfeld finden lassen, wenn sie gezielt danach suchen. Entscheidend ist die strategische Projektzielsetzung, die sich in der Code-Qualität direkt niederschlägt. Fairerweise sollten alle Beteiligten diese strategische Ausrichtung von vornherein kennen; so wird der vorprogrammierte Frust über den „Crappy Code“ vermieden.
Hinterlasse jetzt einen Kommentar