Interview mit Dr. Mirko Seifert

Fifty Shades of Red: Wie man es schafft, dass Entwickler (endlich) unter ihrer eigenen (schlechten) Software leiden

Hartmut Schlosser

Dr. Mirko Seifert

Entwickler sollen unter ihrer eigenen schlechten Software leiden – mit dieser Prämisse gehen Mirko Seifert und Florian Heidenreich (DevBoost GmbH) in ihren Talk auf der JAX 2016. Warum dieses Leiden aber letztlich zu besserer Software führt, und was man tun kann, dass Software-Tests nicht als schmerzvolle Nebenbeschäftigung angesehen wird, erklärt uns Mirko Seifert im Interview.

JAXenter: „Wie man es schafft, dass Entwickler (endlich) unter ihrer eigenen (schlechten) Software leiden“– so habt Ihr euren JAX-Talk untertitelt. Mal abgesehen von euren offenbar sadistischen Neigungen – weshalb wollt ihr die Entwickler leiden lassen?

Mirko Seifert: Es geht uns nicht primär darum, Entwickler leiden zu lassen, aber wir sind davon überzeugt, dass wichtige Feedback-Mechanismen in der Softwareentwicklung zu kurz kommen. Die meisten Entwickler bekommen nur sehr indirekt eine Rückmeldung darüber, wie die Nutzer ihrer Software diese empfinden. Oft fehlt ein direkter Kommunikationskanal vom Endkunden zum Entwickler. Performanceprobleme, funktionale Fehler oder auch Usability-Probleme müssen über mehrere Instanzen kommuniziert werden, um endlich bei demjenigen anzukommen, der diese Probleme lösen kann. Wenn wir bessere Software wollen, muss sich das ändern.

Das Feedback zum Entwickler muss übrigens auch nicht per se negativ sein. Wenn ich als Entwickler sehe, dass meine Applikation im Produktionsbetrieb reibungslos funktioniert, kann das eine sehr große Motivation sein.

JAXenter:  Das hört sich ein wenig so an wie die Diskussionen um DevOps: Hier wie da sind es getrennte Abteilungen, die nichts von den jeweiligen Anforderungen und Problemen wissen und so gegeneinander statt miteinander arbeiten. Stimmt das Bild?

DevOps geht uns nicht weit genug.

Mirko Seifert: DevOps ist ein Schritt in diese Richtung, uns geht das aber nicht weit genug. Zu einer Software gehören nicht nur die Entwickler und die Administratoren, sondern eben auch die Endnutzer. Die Probleme und Anforderung der Nutzer zu kennen, ist letztlich entscheidend für den Erfolg. Wenn wir genau sie außen vor lassen, brauchen wir uns nicht wundern, wenn Softwareprojekte scheitern oder eben schlechte Software unseren Alltag beherrscht.

JAXenter:  Gehen wir mal ins Detail: „Fifty Shades of Red“ nennt ihr den JAX Talk ja. Wie schafft man es, dass z.B. ein Performance-Problem dem Entwickler als „Rot“ angezeigt wird?

Mirko Seifert: Das ist ganz einfach. Wir müssen unsere Anwendungen mit entsprechenden Monitoring-Mechanismen versehen, die Probleme zur Laufzeit erkennen. Zum Beispiel ist es möglich, langlaufende Datenbankabfragen oder Request Time Outs zu protokollieren. Dabei kann man auch erfassen, welche Zeilen im Code davon betroffen sind. Diese „Protokolle“ müssen dann dem Entwickler zugänglich gemacht werden. Idealerweise in der IDE, denn dort hält sich der Entwickler ja die meiste Zeit auf. Aber wie das im Detail aussieht, zeigen wir in unserem Talk.

JAXenter: Welche Schwachstellen im Code kann man so behandeln? Gibt es je nach Problemtyp einen anderen Rotfarbton?

Mirko Seifert: Die Anwendungsfälle sind sehr vielfältig. Performanceprobleme sind ein typischer Einstieg in das Thema. Sie treten oft nur in Produktivumgebungen oder unter Last auf und sind gleichzeitig einfach zu überwachen. Unerwartete Exceptions sind ein weiteres Beispiel. Man kann aber noch sehr viel weiter denken. Bei Interaktionen mit UIs kann man protokollieren, an welche Stellen (z.B. bei welchen Eingabefeldern) die meisten Benutzer ungültige Werte eintragen. Wenn die Mehrheit der Nutzer Schwierigkeiten hat, ein Formular korrekt auszufüllen, dann muss das Design bzw. die Oberfläche überdacht werden. Ähnliches gilt z.B. für Menüpunkte, die kurz hintereinander angewählt werden, weil der Benutzer unsicher ist, welcher Menüpunkt der richtige ist. Diese Dinge kann man ohne weiteres protokollieren und an die Entwickler zurückmelden.

Die Verwendung von verschiedenen Farbtönen für unterschiedliche Probleme ist dann genau das Mittel, um diese Informationen zugänglich zu machen. Es muss übrigens auch nicht immer Rot sein.

JAXenter:  Bei „Fifty Shades“ geht es u.a. ja um die Lust am Schmerz. Habt ihr ein Rezept, damit das doch oft wenig beliebte Software-Testen für Entwickler etwas spaßiger wird? Schließlich wollen und sollen Entwickler ja eher Programmieren als Testen.

Softwareentwickler zum Testen zu motivieren, ist ein Thema für sich.

Mirko Seifert: Softwareentwickler zum Testen zu motivieren, ist eigentlich ein Thema für sich. Ich empfinde es oft als schizophren, wenn Entwickler ungern testen, aber sich dann darüber beklagen, dass sie ständig nur Bugs fixen müssen (statt Features zu entwickeln). Um mehr Spaß beim Testen zu haben, kann man einfach einen kleinen Wettbewerb daraus machen. Ein Entwickler schreibt dabei Tests, während der andere das entsprechende Feature implementiert. So wird ein Spiel daraus, bei dem jeder versucht, besser zu sein als der andere.

JAXenter: Was ist die Kernbotschaft eurer Session? Was sollten die Leute auf jeden Fall mit nach Hause nehmen?

Mirko Seifert:  Ich denke, die Kernaussage ist, dass es einfach ist, bessere Software zu schreiben, wenn wir nur mehr Feedback von unseren Nutzern bzw. über das Verhalten der Software im Produktivbetrieb bekommen. Oder anders herum: Wenn wir genau das nicht tun, wird das Ergebnis immer schlechte Software sein.

JAXenter: Vielen Dank für dieses Interview!

Lesen Sie auch: Wir brauchen eine neue oberste Direktive für Software-Architektur: “Make IT changeable!”

5643578805715ec456ec34ceversion292sizefullDr. Mirko Seifert ist Mitgründer und Geschäftsführer der DevBoost GmbH. Er entwickelt seit mehr als zwanzig Jahren Software und ist Committer in verschiedenen Open-Source-Projekten (u.a. EMFText, JaMoPP, JUnitLoop). Mirko veröffentlicht regelmäßig Artikel im Eclipse und im Java Magazin und spricht auf verschiedensten Veranstaltungen.
Geschrieben von
Hartmut Schlosser
Hartmut Schlosser
Content-Stratege, IT-Redakteur, Storyteller – als Online-Teamlead bei S&S Media ist Hartmut Schlosser immer auf der Suche nach der Geschichte hinter der News. SEO und KPIs isst er zum Frühstück. Satt machen ihn kreative Aktionen, die den Leser bewegen. @hschlosser
Kommentare

Hinterlasse einen Kommentar

1 Kommentar auf "Fifty Shades of Red: Wie man es schafft, dass Entwickler (endlich) unter ihrer eigenen (schlechten) Software leiden"

avatar
400
  Subscribe  
Benachrichtige mich zu:
Max Maier
Gast

Problem erkannt – falsche Schlüsse gezogen. Warum sollen Software-Entwickeler unter dem Leiden was sie implementieren? Oft sind nicht diese schuld an unintuitiver und langsamer Software sondern Management, Projektleiter und Business Analysten. Diese formulieren Anforderungen und priorisieren notwendige Aufgaben. Entwickler setzen diese Anforderungen nur in einem vorgegebenen Zeitfenster um (und hinterfragen ggf. das ein oder andere). Will man „bessere“ Qualität, muss man Entwicklern mehr Zeit geben. Dann haben diese ggf. auch mal die Zeit die eigene Software ausführlicher zu testen.