Ger Cloudt begann in den frühen 1980er Jahren mit Lochkarten und lernte dabei wertvolle Lektionen über die Entwicklung guter Software. Der neue Trainer des High Tech Institute teilt seine Erkenntnisse über das Zusammenspiel von Prozessen und Fähigkeiten, über die Messung von Softwarequalität und über die Förderung einer Unternehmenskultur, in der Ingenieure hochwertige Software liefern können.
Ger Cloudts erste Begegnung mit der Programmierung war die Verwendung von Lochkarten während seines Elektronikstudiums an der Fontys Venlo University of Applied Sciences in den frühen 1980er Jahren. Nach seinem Abschluss begann er eine Karriere als digitaler Elektronikingenieur, wobei er sich sowohl auf das Design digitaler Schaltungen als auch auf die Entwicklung von Software zur Steuerung von Mikroprozessoren konzentrierte. „Das war in Assembler und ich erinnere mich, dass ich wirklich unstrukturierten Spaghetti-Code erstellt habe“, erinnert sich Cloudt. „Das machte die Fehlersuche und -behebung natürlich äußerst schwierig und erteilte mir eine harte Lektion, dass es einen besseren Weg geben muss.“
Glücklicherweise bekam Cloudt bei seinem zweiten Auftrag einen erfahrenen Mentor zur Seite gestellt, der ihm beibrachte, mit strukturiertem Pseudocode zu beginnen und diesen dann in Assembler umzuwandeln. „Das war das erste Mal, dass ich erlebte, dass Struktur die Erstellung von robustem Code erleichtern und die Fehlersuche vereinfachen kann.“ Diese Erfahrung führte dazu, dass er ein paar Jahre später in die Softwareentwicklung wechselte.
Prozess versus Fähigkeit
Cloudt arbeitete anschließend bei Philips Medical Systems als Softwareentwicklungsingenieur und später als Softwarearchitekt, wo er lernte, wie sich Prozesse und Fähigkeiten gegenseitig ergänzen. „Um Handlungen auszuführen, braucht man ein bestimmtes Fähigkeitsniveau, während Handlungen durch einen Prozess strukturiert werden müssen, um Ergebnisse zu erzielen. Die Bedeutung von Prozessen oder Fähigkeiten hängt jedoch von der Art der Aufgabe ab. Einerseits gibt es Aufgaben wie die Arbeit am Fließband oder der Aufbau der gekauften Ikea-Möbel, die einen strengen Prozess, aber nur minimale Anforderungen an die Fähigkeiten erfordern. Andererseits sind Aufgaben wie das Malen der Mona Lisa, wie es Leonardo da Vinci getan hat, weniger prozessorientiert, erfordern aber ein hohes Maß an Fähigkeiten, über die nur wenige verfügen.“
''I increasingly believed that skill level is more important than processes for software engineers. A process can facilitate applying your skills, but with inadequate skills, no process will help.''
In dieser Zeit beobachtete Cloudt eine starke Betonung der Prozesse in der Softwareentwicklung. „Dies war die Zeit, in der das Capability Maturity Model aufkam, das auf die Verbesserung der Softwareentwicklungsprozesse abzielte. Doch selbst wenn Prozesse vorhanden sind, sind Fähigkeiten weiterhin unerlässlich. Bei dem Streben nach hohen CMM-Niveaus besteht die Gefahr, dass die Fähigkeiten unterbewertet werden.“ Diese Einsicht wurde noch verstärkt, als Cloudt bei Philips Medical Systems in eine Führungsposition wechselte und Teams mit sechzig Mitarbeitern leitete. „Das Erreichen eines bestimmten CMM-Levels wird schnell zu einem Ziel an sich, und wie Goodharts Gesetz besagt: Wenn eine Maßnahme zu einem Ziel wird, hört sie auf, eine gute Maßnahme zu sein. Ich war zunehmend der Meinung, dass für Software-Ingenieure Fähigkeiten wichtiger sind als Prozesse. Ein Prozess kann die Anwendung Ihrer Fähigkeiten erleichtern, aber bei unzureichenden Fähigkeiten hilft kein Prozess.“
Cloudt lernte später die Bedeutung von Transparenz kennen. „In meiner ersten Rolle im Qualitätsmanagement musste ich mich mit einem Problem befassen, bei dem es um die Integration von zwei verschiedenen Software-Stacks ging. Ein Team entwickelte NFC-Software, ein anderes arbeitete an Software für ein sicheres Element. Beide zu integrieren, erwies sich als Herausforderung. Als ich mir die Sache genauer ansah, entdeckte ich, dass die Teams zwar ihre Software testeten, Testfehler aber nicht systematisch überwacht wurden. Also erstellten wir täglich aktualisierte Dashboards mit den Testergebnissen, und die Entwickler diskutierten täglich über die Ergebnisse. Wir teilten die Dashboards sogar mit dem Kunden. Natürlich sah anfangs alles rot aus, aber das war ein starker Anreiz für die Entwickler, sich zu verbessern. Folglich war das Projekt erfolgreich.“
Lernen durch Teilen
In seiner Funktion als Software R&D Manager bei Bosch verspürte Cloudt das Bedürfnis, seine Erkenntnisse über Softwarequalität mit anderen zu teilen. Er begann damit, Artikel im internen sozialen Netzwerk des Unternehmens sowie auf Linkedin zu veröffentlichen. „Ich erhielt viel positives Feedback, insbesondere von Bosch-Kollegen“, sagt er. „Also beschloss ich 2020, ein Buch zu schreiben: ‚Was ist Softwarequalität?‘. Diese Erfahrung war sehr bereichernd, da sie viel von meinem impliziten Wissen explizit machte und auch Lücken in meinem Wissen aufdeckte.“
In einem Qualitätsausschuss bei Bosch traf Cloudt einen jungen Absolventen mit einem Master-Abschluss in Qualitätsmanagement. Als er den Absolventen fragte, ob er einen Kurs über Softwarequalität belegt habe, war die Antwort negativ. „Daraufhin wandte ich mich an das Doktorandenprogramm für Ingenieure an der Technischen Universität Eindhoven, wo man mich einlud, eine Gastvorlesung zu halten. Schließlich wurde ich Dozentin für einen Qualitätsmanagementkurs.“ Cloudt begann auch, auf Veranstaltungen über Softwarequalität zu sprechen, z. B. auf einer Bits&Chips-Veranstaltung im Jahr 2021, und er führt derzeit zwei Schulungsprogramme am High Tech Institute durch, eines für Ingenieure und eines für Manager. Derzeit ist er Software-Qualitätsmanager für die Entwicklung der Digital Application Platform bei ASML.
Messung der Softwarequalität
Softwarequalität als solche ist nicht messbar, behauptet Cloudt, weil das Konzept so vielfältig ist. „Sie können einige spezifische Aspekte der Softwarequalität messen, die als ‚modellierte Qualität‘ bezeichnet werden. Dazu gehören die zyklomatische Komplexität des Codes, Abhängigkeiten, Codeabdeckung, Zeilenzahl und offene Fehler. Solche Metriken sind nützlich, aber jeder, der sich damit Ziele setzt, sollte sich vor dem Goodhart’schen Gesetz in Acht nehmen.“
Ein wesentlicher Teil der Qualität bleibt unmessbar: die transzendente Qualität. Um dies zu veranschaulichen, vergleicht Cloudt es mit der Bewertung eines Gemäldes. „Sie können die Dicke der Farbe und die Größe der Leinwand messen, aber Sie können nicht die Schönheit des Gemäldes messen. Dasselbe gilt für Softwarequalität: Sie können die Codeabdeckung durch Ihre Unit-Tests messen, aber das sagt nichts darüber aus, ob die Tests gut sind. Dafür brauchen Sie eine Expertenmeinung, die durch die von Ihnen gemessene modellierte Qualität gestützt wird.“
''Never underestimate culture. An organization should foster an environment where software engineers can thrive and deliver excellent design, code and product quality.''
Wenn man über Softwarequalität nachdenkt, werden oft Aspekte wie Modularität, sauberer Code und Benutzerfreundlichkeit genannt. Dies sind Beispiele für Designqualität (z.B. Modularität, Wartbarkeit und Trennung von Belangen), Codequalität (z.B. sauberer Code, Portabilität und Unit-Tests) und Produktqualität (z.B. Benutzerfreundlichkeit, Sicherheit und Zuverlässigkeit). Cloudt zufolge erfordern diese drei Arten von Qualität jedoch ein häufig übersehenes Element: die organisatorische Qualität. „Diese Art von Qualität bestimmt, ob Ihre Organisation in der Lage ist, hochwertige Software zu entwickeln. Aspekte wie Software-Handwerk, ausgereifte Prozesse, Zusammenarbeit und Kultur sind für die organisatorische Qualität entscheidend. Unterschätzen Sie niemals die Kultur. Ein Unternehmen sollte ein Umfeld schaffen, in dem sich Softwareingenieure entfalten und exzellente Design-, Code- und Produktqualität liefern können.“
Geplantes und umgesetztes Design
Es gibt mehrere bekannte Best Practices für die Entwicklung hochwertiger Software, darunter die testgetriebene Entwicklung (TDD) und die Paarprogrammierung, sowie die statische Codeanalyse. Cloudt fügt noch etwas hinzu, das weniger bekannt ist: die statische Designanalyse. „Vielen ist nicht klar, dass es einen Unterschied zwischen dem beabsichtigten Design und dem implementierten Design von Software gibt. Softwarearchitekten dokumentieren ihr geplantes Design in UML-Modellen. Oft besteht jedoch eine Lücke zwischen diesem beabsichtigten Design und seiner Umsetzung in Code. Diese Lücke klein zu halten, ist eine bewährte Praxis. Tools können die Konsistenz zwischen Ihrem Code und den UML-Modellen überprüfen und Warnungen ausgeben, wenn Diskrepanzen auftreten.“
Diese Diskrepanz zwischen beabsichtigtem und umgesetztem Design entsteht oft unter Zeitdruck, zum Beispiel aufgrund von Projektfristen. „In solchen Fällen nehmen Sie eine Abkürzung, indem Sie eine Lösung ‚hacken‘, die es Ihnen ermöglicht, die Frist einzuhalten, wobei Sie weniger Wert auf Qualität legen“, erklärt Cloudt. „Dies ist eine bewusste Entscheidung, um technische Schulden aufgrund von Zeitdruck einzuführen. Auch wenn dies die einzige unmittelbare Lösung sein mag, ist es wichtig, diese technischen Schulden später anzugehen. Nach der Veröffentlichung sollten Sie sich etwas Zeit nehmen, um eine angemessene, qualitativ hochwertige Lösung zu entwickeln. Leider ist das nicht oft der Fall. Manager sollten erkennen, dass sie den Entwicklern Zeit geben müssen, um diese Lücke und diese technischen Schulden abzubauen, um zukünftige Probleme zu vermeiden. Durch ihre Entscheidungen tragen Manager wesentlich zur Qualität des Unternehmens bei und haben damit direkten Einfluss auf die Softwarequalität.“
Dieser Artikel wurde geschrieben von Koen Vervloesem, freier Mitarbeiter bei Bits&Chips.
Die Schulungen 'Softwarequalität für Ingenieure' und 'Verständnis von Softwarequalität für Manager' finden zweimal jährlich statt
auf dem Laufenden halten
Erhalten Sie unsere monatlichen Updates
