Goldene Wasserhähne – Wie wichtig ist Qualität in der Softwareentwicklung?

Stellt man Projektbeteiligten die Frage, ob Qualität von Software wichtig ist, antwortet ein Großteil der Befragten vermutlich mit „Ja”. Jede andere Antwort würde sicherlich weitere, unangenehme Fragen aufkommen lassen. Aber was bedeutet Qualität im Kontext der Softwareentwicklung eigentlich? Und auch wenn es eine Definition von Qualität gibt, ist dies erstmal reine Theorie. Oft werden im Entwicklungsverlauf Entscheidungen getroffen, die der Prämisse, qualitativ hochwertige Software zu schreiben, widersprechen. Wie wichtig ist die Qualität von Software in der Praxis nun eigentlich wirklich und wie schätzt man die Notwendigkeit von Qualität für das eigene Produkt ein? Gibt es eigentlich eine Art Mindestanforderung an Qualität? Warum dies am Ende des Tages eine Kosten-Nutzen-Rechnung ist, erklären wir in diesem Artikel.

Was ist Softwarequalität?

Schlägt man bei Wikipedia „Softwarequalität" nach, findet man dazu folgende Definition:

„Unter Softwarequalität versteht man die Gesamtheit der Merkmale und Merkmalswerte eines Softwareprodukts, die sich auf dessen Eignung beziehen, festgelegte oder vorausgesetzte Erfordernisse zu erfüllen.“

Was genau kann man darunter in der Praxis verstehen? Der Kunde erwartet Funktionalität, das ist klar. Aus Anwendersicht sollten Bedienelemente reibungslos funktionieren und Automatismen das tun, wofür sie entwickelt wurden – und dies nach Möglichkeit nachvollziehbar und verlässlich. Das ist der offensichtliche Teil der Qualität. Aber wie sieht es unter der Oberfläche aus? Code erfüllt ja nicht nur kurzfristig einen Zweck, sondern liefert als Framework gegebenenfalls auch die Basis für Erweiterungen und trägt somit eine gewisse Verantwortung im Sinne der Nachhaltigkeit. Auch die Lebenserwartung an eine zentrale Codebasis ist hoch. Wenn also Code-Qualität im Softwareentwicklungsprozess ein Thema ist, hat jedes Team, sogar jede einzelne Entwicklerin, sicher ihre eigene Vorstellung davon, wie dies letztendlich umgesetzt wird. Des Weiteren besteht ein Produkt ja auch nicht ausschließlich aus Quellcode. Auch an die Abnehmer der Software muss hier gedacht werden. Wer nimmt die Software in Betrieb? Gibt es Abhängigkeiten zwischen Komponenten? Welche Parameter müssen überwacht werden? Zum Produkt gehören dann auch technische und fachliche Dokumentationen, Grafiken oder weitere Artefakte. Um die Qualität eines Produkts in der Gesamtheit zu betrachten, müssen hier also alle der genannten Teilbereiche berücksichtigt werden.

Was ist qualitativ hochwertiger Code?

Tests, Fakten, Analysen

Um die Qualität von Quellcode zu messen, gibt es laut landläufiger Meinung einige Indikatoren und zu deren Ermittlung natürlich entsprechendes Tooling. Hier sei die statische Codeanalyse in Form von Werkzeugen wie beispielsweise SonarQube erwähnt, die uns Metriken über Testabdeckung, Verschachtelungstiefe und Komplexität erstellen.

Automatisierte Tests ermöglichen EntwicklerInnen einen gesunden Schlaf. Doch das Schreiben dieser Tests kostet Zeit. Wie viel Testing ist genug? Natürlich kann die Anwendung ohne automatisierte Tests funktionieren, aber ein unzureichendes Sicherheitsnetz in Form von fehlenden Tests lässt einen raschen Abfall der Qualität durch zukünftige Änderungen (Regression) zu. Hier ist also abzuwägen, welche Teile der Software kritisch sind und hinreichend mit Tests abgedeckt werden sollten.

Die Testabdeckung ist ein gern genutztes Mittel zur Bewertung des Reifegrades von Software. Doch eine hohe Testabdeckung heißt in keinster Weise, dass der getestete Code fehlerfrei ist. Sie gibt lediglich an, dass die entsprechende Code-Stelle von einem Test durchlaufen wird. Über die Qualität der Tests – und damit des Codes – trifft diese Metrik keine Aussage. Eine sehr niedrige Coverage kann jedoch darauf hindeuten, dass kritische Pfade des Quellcode ungetestet sind. Ob diese Analyseergebnisse also hilfreich sind, muss von Fall zu Fall bewertet werden. Solche Metriken generell zu haben ist jedoch sicher nicht verkehrt.

Code-Komplexität ist allerdings wirklich oft ein guter Indikator. Hier sollten auffallende Codestellen geprüft und bestenfalls simplifiziert werden, was die Nachvollziehbarkeit und somit auch die Wartbarkeit erhöht.

Clean Code

Ein Qualitätsmerkmal, welches eher schlechter messbar, jedoch nicht zu unterschätzen ist, ist sauberer, gut strukturierter Quellcode. Code wird weitaus öfter gelesen als geschrieben, wodurch Verständlichkeit und Struktur enorm zur Qualität von Software beiträgt. Auch wenn es zu Beginn etwas länger dauert, eine passende Struktur, gemeinsame Regeln für das Team und einzusetzende Patterns zu erarbeiten, gewinnt man hinten raus oft Zeit. Auch die Wartbarkeit wird durch diese Investitionen deutlich erhöht. Da dies wie erwähnt aber nicht wirklich messbar ist, entstehen oft Diskussionen. Dann fallen Sätze wie: „Investieren wir zu viel Zeit in Clean Code?” oder: „Wollen wir in Schönheit sterben?”. Häufig stehen sich hier dann Best Practices wie YAGNI oder das Pareto Prinzip und die Voraussicht, Dinge für die Zukunft zu entwickeln, gegenüber. An dieser Stelle ist es wichtig, dass das Team eine gemeinsame Sichtweise dafür entwickelt, wie „clean” der Code wirklich sein muss.

Sicherheit

Während Dinge wie sauberer Code und Testabdeckung streitbar sind, gilt bei dem Thema Sicherheit ein besonderes Augenmerk, denn hier ist es umso mehr gefährlich, ressourcenbedingte Abstriche in Sachen Qualität zu machen. Unabhängig, um welche Art von Software es sich handelt, sollten beispielsweise Authentifizierungsmechanismen immer produktionsfertig konzipiert und implementiert werden. Es wäre nicht das erste Mal, dass ein hemdsärmelig gebauter Basic-Auth-Login einer vormals als Wegwerf-Prototyp ins Leben gerufenen Anwendung letztendlich doch in Produktion betrieben wird. In puncto Sicherheit sollte es also definitiv einen Minimum-Standard-Anspruch an Qualität geben.

Dokumentation

Ein unbeliebtes Thema. TechnikerInnen konzipieren und entwickeln Software, und das tun sie verständlicherweise am liebsten. Ungern wird über Dokumentation gesprochen, noch weniger gern wird diese geschrieben und aktuell gehalten. Doch auch diese gehört zu einer guten Software dazu, und eine qualitativ gute Dokumentation erfreut Betreibende und NutzerInnen der Software. Hier sollten wichtige Informationen zur Inbetriebnahme genauso wenig fehlen wie klare, zielgruppengerechte Anweisungen zur Nutzung der Oberfläche. Auch die Formulierungen sind wichtig. Hier gilt der gleiche Grundsatz wie auch beim Sourcecode: Die Mühe der einmaligen Erstellung ist es wert, den vielen Lesenden einen guten Leitfaden an die Hand zu geben.

Anforderungsmanagement – Was sollen wir überhaupt abliefern?

Jede Entwicklerin, die was auf sich hält, hat sicherlich so etwas wie einen Mindestanspruch an die Qualität der bereits erwähnten Themen-Bereiche. Doch Ideologie hin oder her, letztendlich schreiben wir Software selten für uns allein, sondern zusammen mit anspruchsvollen TeamkollegInnen, im Auftrag von kleinlichen Vorgesetzten, programmieren gegen komplizierte Schnittstellen anderer Dienstleistenden, übergeben unser Produkt an gestresste Betreibende und erfüllen hoffentlich die Erwartungen zahlender Endnutzenden. An uns hängt nun die ehrenvolle Aufgabe, den Anforderungen aller zu genügen.

Um ein gutes Produkt zu kreieren (a.k.a es allen Stakeholdern Recht zu machen) ist es substanziell wichtig, deren Anforderungen überhaupt erst einmal zu kennen.

Funktionale Anforderungen (= offensichtliche Qualität)

Bei der Betrachtung der funktionalen Aspekte von Software, also den vom Kunden geforderten Features, ist die Anforderungsanalyse zwar oft nicht einfach, aber der Weg dahin ist klar. Meistens sagt uns der Kunde, was er braucht … Beziehungsweise er teilt uns mit, was er „glaubt" zu brauchen – aber das ist ein anderes Thema. Die Umsetzung der geforderten Features und somit auch deren fachliche Qualität werden also vom Kunden selbst bei regelmäßigen Reviews, Übergaben und fachlichen Tests überprüft. Hierzu gibt es meist klare Vorgaben und Kriterien, vielleicht sogar schon genaue Anforderungen an die Kundendokumentation. Easy Job.

Nicht-funktionale Anforderungen (= nicht-offensichtliche Qualität)

Die Erfassung der nicht-funktionalen Anforderungen ist hier deutlich schwerer. Einige Bedingungen wie Verfügbarkeitsgarantien und sichergestellte Antwortzeiten (SLAs) lassen sich zwar durch konkrete Zahlen definieren und dementsprechend auch prüfen, doch bei Anforderungen an die Qualität des Quellcodes wird die Definition hingegen schwammig. Obwohl jeder Kunde sicher wünscht, dass die bestellte Software beispielsweise weitgehend fehlerfrei und einfach zu warten ist, gibt es für diese Kriterien leider keine allgemeingültige Maßeinheit.

Ein gemeinsames Verständnis von Code-Qualität entwickeln

Anforderungen an die harten, messbaren Kriterien sollten unbedingt in den Anforderungsdokumenten (User Stories, Abnahme-Kataloge etc.) festgehalten sein. Dies lässt sich dann bei der Abnahme anhand der vereinbarten Kriterien prüfen und abhaken. Aber was hingegen Code-Qualität für die einzelnen Mitwirkenden bedeutet, ist schwer in Zahlen auszudrücken.

Wenn etwas nicht in puren Fakten zu messen ist, muss eine andere „Maßeinheit” gefunden werden. In Bezug auf die nicht messbaren Kriterien wie die Qualität des erzeugten Quellcodes benötigt es also eine Vereinbarung, wie viel Mühe sich die EntwicklerInnen geben, den Code so effektiv wie nötig, aber so nachhaltig wie möglich zu schreiben, ohne das verfügbare Budget zu sprengen.

Code-Qualität kostet Zeit (= Geld) und ist eine Investition in die Zukunft. Je „hochwertiger” der Quellcode ist, desto stabiler und länger arbeitet die Software. Wie sinnvoll diese Investition ist, entscheidet die Art unseres Produktes. Dies kann man aber nicht unbedingt in Zahlen ausdrücken. Hier hilft, wie so oft, Kommunikation. Durch den gegenseitigen Austausch und eine sinnvolle Beratung muss ein Gefühl dafür entwickelt werden, inwieweit man sinnvoll Arbeit investiert oder kostbare Zeit für die berühmten „goldenen Wasserhähne" verschwendet.

Fun Fact zu „goldene Wasserhähne"

Es gibt ja immer wieder Begriffe und Redewendungen, die sich in gewissen Branchen etabliert haben. In Softwareprojekten, speziell in Diskussionen (zwischen Stakeholdern und EntwicklerInnen) über Qualität, tauchen „goldene Wasserhähne" überraschend häufig auf. Doch woher kommt der Begriff eigentlich? Ein definitiver Ursprung der Phrase ist nicht einwandfrei ermittelbar, sie lässt sich aber auch in historischen Zitaten finden:

„Auch aus goldenen Wasserhähnen kommt nur ganz gewöhnliches Wasser.” – Helmut Glaßl

Welchen Arten von Software müssen wir unterscheiden?

Natürlich gibt es viele unterschiedliche Möglichkeiten, Arten von Software zu differenzieren. Für unsere Zwecke – zur Unterscheidung der Notwendigkeit von Qualität – reicht jedoch die Unterteilung in folgende Kategorien völlig aus:

Proof of Concepts / Prototypen

Mit PoCs werden häufig komplett unbekannte Wege beschritten, sowohl im softwaretechnischen als auch im fachlichen Sinne. Da meist „Wegwerf-Code" produziert wird, ist der Fokus auf Qualität an dieser Stelle eher gering. Der Prototyp soll zwar Konzepte auf den Prüfstand stellen, aber wird in dieser Form wohl nie in Produktion gehen und auch nicht von einem Wartungsteam übernommen werden. Der ein oder andere Bug wird hier wohl auch verziehen, solange die Erprobung die erwarteten Ergebnisse bringt.

Produktionssoftware

Sind wir über den Status eines Prototypen hinaus oder haben direkt mit einer Architektur gestartet, die Bestand hat, spielt Qualität eine große Rolle. Einerseits ist hier eine fehlerfreie Bedienung gefordert, denn möglicherweise steht eine große oder wichtige Nutzerbasis dahinter. Auf der anderen Seite wird die Codebasis lange leben, durch viele Hände gehen und vielleicht auch von einem komplett neuen Team übernommen, gewartet und erweitert werden. Hier ist dann auch die Qualität des Quellcodes wichtig, denn kein Projekt-Einsteiger möchte sich durch dutzende Zeilen schwer verständlichen Quellcodes quälen.

Kritische Software (bspw. im Gesundheits- oder Finanzbereich)

Vielleicht könnte man diese Kategorie als Erweiterung der Produktionssoftware sehen, jedoch mit einem weitaus strengeren Fokus auf Qualität. Bugs und Unklarheiten verursachen hier deutlich mehr „Impact", falls versteckte Fehler oder schlecht zu wartender Code zu häufigen Iterationen oder langen Durchlaufzeiten führen. Von monetären oder gar personellen Schäden durch auftretende Laufzeitfehler ganz zu schweigen.

Fazit

Und wer bestimmt nun, wie wichtig Qualität für ein Softwareprojekt ist? Ganz einfach, nicht die persönlichen Ansprüche, sondern das Projekt selbst. Schlüsselfaktoren sind hier die Art der Software, die Anforderungen des Kunden und die Rahmenbedingungen, in der sich unser Code bewegt. Wie bei jeder anderen Ressource auch sollte es in puncto Aufwand für Qualität unser Ziel sein, diese in einem wirtschaftlichen Maße einzusetzen. Es dankt einem niemand, wenn endlose Zeit in „goldene Wasserhähne" investiert wird, obwohl es sich von vornherein um Wegwerf-Code handelt. Dabei sollten wir als EntwicklerInnen jedoch handwerklich keine minderwertige Arbeit abliefern, gerade wenn es um kritische Themen wie Sicherheit geht. Oft ist es auch möglich, qualitativ guten Code zu schreiben ohne wahnsinnig viel Aufwand zu betreiben, wenn man im Alltag Dinge wie Verständlichkeit und Erweiterbarkeit im Hinterkopf behält und dies als Minimum-Standard ansieht.