Der ewige Streit um Softwarequalität

Aus diesem Satz: "Wenn wir Zeit in Qualität investieren liefern wir weniger schnell, dafür aber in der Zukunft schneller." ergibt sich direkt das Qualitätsdilemma: "Investieren wir jetzt in Qualität und liefern langsamer als wir es könnten oder investieren wir jetzt nicht in Qualität und riskieren später Probleme mit der Lieferfähigkeit?" Eine einfache Antwort auf das Dilemma, die ich zu oft höre ist: "Qualität bedeutet langfristige Geschwindigkeit => Qualität = Geschwindigkeit." Das stimmt aber nicht. Die meisten Entwickler wissen auch, dass das nicht stimmt. Je mehr Qualität wir machen, desto schneller sind wir, ist ein Trugschluss. Je höher die Qualitätsansprüche, desto länger dauert die Umsetzung. Testsuites, DoDs, Refactoring, Boy Scout Regel, Architekturdiskussion, Code Review, Tooling, Automatisierung, Pair Programming, Mob Programming, Qualitätsmessungen usw. kosten alle Zeit. Einfach den maximal möglichen Aufwand in Qualität zu investieren, das lohnt sich nicht. Zu wenig in Qualität zu investieren lohnt sich nur kurzfristig und führt ins Chaos. Wie findet man also ein sinnvolles Mittelmaß zwischen zu viel und zu wenig? Wie findet man die Qualitätsmaßnahmen, die mehr Mehrwert als Aufwand erzeugen? Und wieso streiten sich die Entwickler seit Jahrzehnten immer noch über dieses Thema?

Zum einen streiten wir uns wegen der Ungewissheit. Es gibt keine klare Heuristik, die uns sagen kann, ob eine Maßnahme sinnvoll ist oder nicht. Ob wir ein Qualitätsproblem in unserem Produkt haben, merken wir meist erst Monate oder Jahre später. Wenn wir viele Bugs produzieren, bei Anpassungen viele Abhängigkeiten haben oder Schwierigkeiten bekommen, unseren Code zu verstehen haben wir ein Qualitätsproblem. Es ist aber schwer, im Voraus zu wissen, ob eine Entscheidung zu einem Qualitätsproblem führen wird, ob es eine bessere Entscheidung gibt und ob der Aufwand dem Nutzen entspricht. Mehr als ein fundiertes Bauchgefühl hat selbst der erfahrene Entwickler nicht zu bieten.

Zum anderen streiten wir uns wegen unserer eigenen Egos. Überhaupt hochqualitative Software zu produzieren erfordert Können. Der Entwickler sieht sich als guter Handwerker und baut seine professionelle Identität gerne um die sorgfältige Arbeitsweise herum auf. Wenn nun ein anderer Entwickler für weniger Qualität argumentiert, wird es schon fast zu einer Frage des Berufsethos, sich dafür einzusetzen, dass die Qualität so hoch wie möglich ist. Der Entwickler, der für weniger argumentiert hat, interpretiert den Qualitätsanspruch des anderen darum leicht als indirekte Kritik am eigenen Können. Der Entwickler, der für mehr argumentiert hat, konfrontiert die Gegenseite manchmal unbeabsichtigt mit dem Vorwurf, es mangele ihr an Professionalität. Der entsprechende Konflikt ist oft nicht mehr als ein Missverständnis und schadet der objektiven Diskussion.

In der echten Welt ist die Annahme, dass Unterschiede im Können existieren, leider nicht immer ein Missverständnis. Es gibt Entwickler, die selbst nach vielen Jahren Berufserfahrung in Sachen Qualität in vielen Bereichen immer noch auf einem Beginner Level sind und Software produzieren, die nur sehr schwer wartbar und erweiterbar ist. Wenn man seine professionelle Identität rund um die Qualitätsarbeit aufbaut, passiert es schnell, dass man diese Entwickler als ‘unprofessionell’ einstuft und entsprechend behandelt. Dieser Kapitalfehler ist mir in meinem ersten Projekt unterlaufen und ich habe es dort nie geschafft, in irgendeiner Weise Einfluss auf den Arbeitsstil einiger Entwickler zu nehmen. Der wertschätzende und respektvolle Umgang ist in solchen Fällen essenziell und erfordert gute Soft Skills. Hierzu könnte man ein komplettes Buch verfassen, das den Rahmen dieses Artikels sprengen würde. Grundsätzlich ist die Einstellung “Das sind einfach keine Profis und die sind schuld, wenn sie alles, was ich Ihnen erkläre, in den Wind schlagen” wenig erfolgversprechend.

Wir streiten uns auch wegen des Lieferdrucks. Wenn Druck auf einen Menschen ausgeübt wird, verändert sich dadurch seine Weltsicht. Automatisch räumen wir dann den Argumenten mehr Gewicht ein, die den Druck kurzfristig reduzieren würden. Die Korrelation zwischen schlechter Softwarequalität und konstant hohem Lieferdruck ist nicht umsonst in der agilen Welt gut bekannt. Manchmal sehen wir den Source Code von Projekten, die unter konstantem Hochdruck entwickelt wurden und lassen uns leicht dazu hinreißen, Inkompetenz zu vermuten. Dabei hatten die Entwickler einfach keine andere Wahl, als in dieser Form zu liefern, unabhängig von ihrem tatsächlichen Können.

Wie Druck und Stress empfunden werden, das ist sehr individuell. Im selben Projekt können zwei Entwickler sitzen, der eine ist die Ruhe selbst und der andere glaubt, unbedingt und so schnell wie irgendwie möglich ein Feature live bringen zu müssen. Dieses Stressempfinden hängt stark vom Charakter ab, aber auch von der Resilienz, die man über eine längere Karriere hinweg entwickeln kann. Wegen unterschiedlicher Wahrnehmungen des Projektdrucks fällt es uns dann schwer, uns einig zu werden. Was dem einem wie das absolute Minimum erscheint ist für den anderen ein Luxus, den man sich unmöglich leisten kann.

Wir streiten, weil zu viel Qualität kein 'echtes' Problem ist. Fast jeder Entwickler hat irgendwann Erfahrung in einem Projekt mit Qualitätsproblem sammeln müssen. Diese Projekte können ein Albtraum sein. Simple Aufgaben brauchen eine Ewigkeit. Irgendwas funktioniert immer nicht, obwohl es selbstverständlich sein sollte. Man kämpft konstant mit unerwarteten Nebeneffekten und Bugs. Immer wieder verbringt man Stunden damit, tausende Zeilen zu durchwühlen auf der Suche nach Antworten auf simple Fragen. Man vergleiche dies mit einem Projekt mit einer hohen Softwarequalität, in dem man jeden Sprint ein schönes, bugfreies, sauber integriertes Inkrement liefert, zur Freude des Managements und der Stakeholder. Zu viel Qualität ist deutlich weniger verheerend als zu wenig Qualität. Ein Projekt mit zu viel Qualität ist grundsätzlich gesund, man hätte diesen Zustand aber mit weniger Aufwand erreichen können. Im Zweifelsfall ist die pragmatische Wahl eher ein bisschen zu viel als zu wenig zu machen auch nicht falsch. Wir haben aber als Entwickler eine Verantwortung, die Kosten und den Nutzen der Qualität abzuwägen. Andere sind darauf angewiesen, unserer Einschätzung zu vertrauen. Wenn wir wissentlich auf exzessive und verschwenderische Maßnahmen bestehen, verletzen wir das in uns investierte Vertrauen aufs gröbste. Tatsächlich ist das aber sehr selten der Fall, Exzesse leisten sich die wenigsten Entwickler. Trotzdem schwebt der Vorwurf des mangelnden Pragmatismus latent im Raum, wenn jemand für - in unseren Augen - zu viel Qualität argumentiert. Im schlimmsten Fall wird sogar ein Vertrauensbruch unterstellt.

Was können wir also aus diesen Punkten mitnehmen? Es gibt vier typische Gründe, warum es zum Streit kommt. Dabei kann der Streit gut sein, solange er produktiv ist: Wenn sich zwei Menschen mit unterschiedlichen Ansichten streiten und dabei gemeinsam eine Lösung erarbeiten, war das sinnvoll investierte Zeit. Für ein funktionierendes Entwicklerteam mit einer gemeinsamen Code Ownership ist der produktive Streit unabdingbar. Leider ist Streit aber oft keineswegs produktiv. Die vier genannten Themen treten in allen möglichen Kombinationen auf und können dazu führen, dass wir uns auf unsere Positionen zurückziehen und von dort aus Grabenkämpfe beginnen, anstatt gemeinsam an einer sinnvollen Abwägung zwischen Kosten und Nutzen zu arbeiten. Wir missverstehen uns öfter als nötig.

Wenn man einem der genannten Streitgründe identifiziert hat, hoffe ich, dass diese Handlungsempfehlungen helfen, den ein oder anderen Konflikt ein wenig abzukürzen oder in konstruktive Bahnen zu lenken:

• Streitgrund ‘Ungewissheit’: Häufig haben wir ein unterschiedliches Bauchgefühl und das ist ok. Es wird nicht immer eine eindeutig richtige Lösung geben. Anstatt bis zur Resignation einiger Gesprächsteilnehmer ein Thema zu diskutieren lohnt es sich manchmal eher, sich vorläufig auf ein paar erste Experimente zu einigen, wenn es keine neuen Argumente gibt. Es ist auch nicht alles eine längere Diskussion wert. "Ich hätte das anders gemacht, der Ansatz passt mir aber auch sehr gut" ist ein Satz, den man von mir manchmal hört.
• Streitgrund ‘Ego’: An den eigenen Soft Skills zu arbeiten empfiehlt sich, weil sie dabei helfen können, das Gesagte objektiver zu verarbeiten und sich nicht persönlich angegriffen zu fühlen. Wenn man sich selbst dabei ertappt, einigen Kollegen zu wenig Wertschätzung entgegen zu bringen, kann es helfen, sich selbst einige Fragen zu stellen, zum Beispiel: "Was hat der Kollege gut gemacht? Was kann der Kollege sehr gut? Was gefällt mir an der Arbeitsweise des Kollegen?" Dennoch kann es vorkommen, dass wir unabsichtlich andere angreifen oder uns selbst angegriffen fühlen. In beiden Fällen lohnt es sich, unsere Differenzen nicht stillschweigend in einen kalten Krieg eskalieren zu lassen. Die meisten Konflikte und Provokationen verlieren ihre Schärfe, wenn man unter vier Augen darüber spricht. Andernfalls empfiehlt es sich, einen neutralen dritten als Mediator hinzu zu ziehen oder mit einem Unbeteiligten ein Coaching Gespräch zu suchen.
• Streitgrund ‘Lieferdruck’: Vielleicht reden wir über Softwarequalität, wenn wir erstmal über Lieferdruck reden sollten. Ich habe ein paar Mal erlebt, dass viel von dem Streit um Qualität von selbst verschwunden ist, als wir uns stattdessen mit dem Thema: "Wie können/wollen wir als Team mit dem Druck von außen umgehen." beschäftigt hatten.
• Streitgrund ‘Zu viel Qualität’: Gelegentlich vergessen wir, dass es auch zu viel des Guten gibt. Unser höchstes Ziel als Entwickler sollte die Lieferfähigkeit sein und nicht die Codequalität. Wir sollten aber auch hier vorsichtig sein, dass wir uns nicht zu voreiligen Vorwürfen hinreißen lassen. Nur weil jemand für 'zu viel' Qualität argumentiert, bedeutet das nicht, das er das Aufwand/Mehrwert-Kalkül vollständig aus den Augen verloren hat.

Ein paar letzte Empfehlungen von mir an die Leser:

Für den Quality Beginner: Bau Dein Skill Set. Der wichtige erste Schritt ist, das richtige Mindset zu entwickeln und auch in der Berufswelt zu leben. Qualitätsarbeit ist kein nice-to-have, sondern absolut unabdingbar. Gerade wenn man noch sehr wenig über Clean Code, Testing und Design weiß, tendiert man sehr leicht dazu, fast jede Qualitätsmaßnahme für ‘zu viel Qualität’ zu halten. Es gibt einen Haufen hilfreiche Literatur (siehe die Empfehlungen am Ende des Artikels). Abseits von der Literatur kann man auch viel lernen durch Experimente, Praxiserfahrung und Zusammenarbeit mit Entwicklern, die bereits Erfahrung mit sauberem Arbeiten haben.

Für den Quality Profi: Diese Streitgründe und die Handlungsempfehlungen erscheinen wahrscheinlich offensichtlich, wenn sie rein rational betrachet werden.  Wir übersehen aber oft das Offensichtliche, sobald die Diskussion einen zu emotionalen Charakter annimmt. Ich hoffe, dass dieser Artikel hilft, die nicht objektiven Teile der Diskussion rund um die Qualität zu reduzieren. Auch zum Thema "konstruktiv streiten" gibt es auch eine Menge an toller Literatur.

Für den Agile Coach: Wenn sich Entwickler über Qualität streiten und Du demjenigen Recht geben möchtest, der in Deinen Augen für mehr Qualität kämpft: Egal ob Du die ‘richtige’ Seite unterstützt oder nicht, hier Partei zu ergreifen ist nicht hilfreich. Das erscheint offensichtlich, ich habe aber auch schon bei sehr erfahrenen und kompetenten Agile Coaches erlebt, wie in der Hitze des Gefechts der Wunsch nach einem qualitätsbewussten Team den nach einem konstruktiv streitenden Team übertrumpft. Wenn der Streit besser laufen könnte und Du helfen möchtest, kannst Du das immer noch tun. Es gibt viele Arten in einem Konflikt zu vermitteln, Einfühlsamkeit einzufordern oder zur Zusammenarbeit an der besten Lösung anstelle eines Grabenkampfes anzuregen.

Literaturempfehlungen:

"Clean Code - Refactoring, Patterns, Testen und Techniken für sauberen Code", Deutsche Ausgabe, Robert C. Martin, 2013, Verlag: mitp/bhv, ISBN-13: 9783826696398

"Domain Driven Design Distilled", Vaughn Vernon, 2016, Verlag: Pearson Education, ISBN-13: 9780134434421

"Nonviolent Communication: A Language of Life: Life-Changing Tools for Healthy Relationships", Marshall B. Rosenberg, 2015, Verlag: Puddledancer Press, ISBN-13: 9781892005281

"Switch: How to Change Things When Change Is Hard", Chip Heath, Dan Heath, 2010, Verlag: Crown Business, ISBN-13: 9780385528757