Developer Friendliness bezeichnet Maßnahmen, die nicht ins Produktivsystem gelangen, sondern ausschließlich dazu dienen, Entwicklern, Testern und anderen Projektbeteiligten den Arbeitsalltag zu erleichtern. Typische Beispiele sind Test-Schnittstellen, Mock-Services und automatisierte Resets von Testumgebungen. Der kurzfristige Aufwand zahlt sich durch dauerhaft eingesparte Zeit und bessere Softwarequalität aus.
Das Wichtigste in Kürze
- Developer-Friendliness-Maßnahmen kosten kurzfristig Zeit, amortisieren sich aber dadurch, dass sie repetitive Aufgaben dauerhaft beschleunigen und so langfristig mehr Kapazität freigeben.
- Eine REST-Schnittstelle als Testeingang für Kafka-Consumer zu implementieren war nach dem ersten Tag Schema F und dauerte danach nur noch eine halbe Stunde pro Schnittstelle.
- Wer manuelles Testen vereinfacht, verbessert automatisch die Qualität, weil Tests häufiger und reibungsloser durchgeführt werden.
- Ein interner Mock-Dienst für externe REST-Abhängigkeiten schützt lokale Entwicklung und automatisierte Tests vor Ausfällen fremder Systeme.
- Wenn ein Entwicklungsteam Frustrationspunkte abbaut, steigt die Stimmung im Projekt, und das wirkt sich direkt auf Motivation und Bindung der Beteiligten aus.
Was Developer Friendliness bedeutet
Developer Friendliness umfasst Maßnahmen, die den Projektalltag von Entwicklern, Testern und anderen Beteiligten angenehmer machen, ohne ins Produktivsystem zu wandern. Sie sind nicht Teil des ausgelieferten Produkts. Sie unterstützen die Menschen, die das Produkt bauen.
Typische Beispiele sind die Automatisierung repetitiver Aufgaben oder Hilfsschnittstellen, die nur intern genutzt werden. Wer alle zwei Tage zehn Minuten lang die gleichen Handgriffe ausführt, statt einen Knopf zu drücken, kennt das Problem, das hier gelöst wird.
Der Vergleich mit User Friendliness macht den Unterschied deutlich. Bei User Friendliness denkt man an einfach bedienbare Oberflächen, Barrierefreiheit oder schnelle Antwortzeiten. Solche Maßnahmen lassen sich leicht rechtfertigen, weil sie sichtbar im Endprodukt landen. Bei Developer Friendliness fehlt dieser sichtbare Bezug, und genau das macht die Argumentation schwieriger.
Warum Developer Friendliness oft hinten runterfällt
Developer Friendliness wird häufig abgelehnt oder verschoben, weil ihr Nutzen nicht im Produkt sichtbar ist. Die Standardeinwände kennt jeder: Wir brauchen zuerst dieses Feature, wir haben kein Geld übrig, wir haben keine Zeit. In Variationen tauchen sie in fast jedem Projekt auf.
Diese Einwände haben in der Realität oft eine Berechtigung. Niemand entwickelt in einer idealen Welt, in der Code perfekt wird, die Testabdeckung lückenlos ist und Zeit keine Rolle spielt. Manchmal sind andere Dinge tatsächlich wichtiger.
Aber nicht immer. Wer die Maßnahmen pauschal nach hinten schiebt, vergisst zwei Punkte. Erstens kosten sie zwar zunächst Zeit, von einem halben Tag bis zu zwei oder drei Wochen, sparen langfristig aber Zeit. Zweitens freuen sich die Menschen, die sie nutzen, selbst dann, wenn die Rechnung nur auf plus minus null aufgeht.
Wie du Developer Friendliness gegenüber dem Management durchsetzt
Das stärkste Argument ist der Zeitfaktor. Wer kurzfristig etwas Zeit investiert und langfristig deutlich mehr spart, gewinnt Zeit für andere Dinge. Diese Rechnung versteht eine Projektleitung schnell.
Der Hebel liegt im frühen Zeitpunkt. Schlägst du eine Maßnahme zu Projektbeginn vor und planst den Aufwand bewusst ein, lässt sich die langfristige Ersparnis sauber begründen. Und diese Ersparnis kann je nach Maßnahme erheblich sein.
Eine Testschnittstelle, die Kafka manuell testbar macht
Eine der wirkungsvollsten Maßnahmen ist eine zusätzliche Schnittstelle, die ausschließlich dem Testen dient. Lars Luthmann beschreibt das an einem Leasing-System aus der Automobilbranche, das aus rund einem Dutzend Microservices bestand. Zwei davon lagen in seinem Teilprojekt: ein Service zur Vertragsverwaltung mit Kundendaten und einer zur Fahrzeugverwaltung.
Die Hauptkomplexität lag nicht im Inneren der Services, sondern in der Kommunikation und der Einbindung in die Geschäftsprozesse. Ein Großteil dieser Kommunikation lief über Apache Kafka. Vereinfacht lässt sich Kafka hier als Message Queue verstehen: Daten werden in ein Topic geschrieben, ein Consumer liest sie aus.
Das Problem: Daten manuell in ein Kafka-Topic zu schreiben, ist umständlich. Die Lösung war, pro Kafka-Consumer eine zusätzliche REST-Schnittstelle zu implementieren, die nur fürs manuelle Testen gedacht war.
REST fiel die Wahl, weil das Tooling ausgereift und niedrigschwellig ist. Damals nutzten alle im Projekt Postman, heute wäre Bruno eine Option. Eine Einstiegshürde gab es nicht. Die Daten aus der REST-Schnittstelle wurden intern exakt so verarbeitet, als kämen sie aus dem Kafka-Consumer. Das System konnte die Herkunft nicht unterscheiden.
Der Aufwand war gering. Für die erste Schnittstelle nahm sich ein Kollege einen guten Tag, jede weitere folgte nach Schema F in etwa einer halben Stunde.
Eine gute Idee zahlt sich über mehrere Use Cases aus
Eine einzelne Testschnittstelle rechtfertigt sich selten über einen einzigen Nutzen. Der eigentliche Wert zeigt sich, wenn man fragt, welche weiteren Anwendungsfälle dieselbe Maßnahme abdeckt. Genau diese Frage hilft, wenn jemand zwar den Nutzen sieht, ihn aber zu klein findet.
Im Leasing-Projekt entstanden mehrere Use Cases aus derselben REST-Schnittstelle:
- End-to-End-Tests: Ursprünglich nicht geplant, später doch gebraucht. End-to-End-Tests kommen mit REST direkt zurecht, ohne Umweg über Kafka-Topics.
- Teaminterne Abnahmetests: Die Business-Analystin testete auf einer deployten Integrationsumgebung, auf der es keinen Schreibzugriff auf die Kafka-Topics gab. Über die REST-Schnittstelle konnte sie den Prozess trotzdem an der richtigen Stelle anstoßen, statt sich zehn Minuten durch alle Nachbarsysteme zu klicken.
- Systemübergreifende Testtermine: In gemeinsamen Telefonkonferenzen mit allen Teilprojekten kam der Prozess manchmal in einem vorgelagerten System zum Stehen. Mit realitätsnahen Messages ließ sich der Prozess ab dem eigenen System fortsetzen.
Der letzte Fall hatte den größten Hebel. Bei rund 30 Personen in so einem Termin spart eine Schnittstelle, die zwei bis vier Wochen früheres Testen ermöglicht, schnell ein Vielfaches ihres Aufwands.
Wie ein Mock fremde Abhängigkeiten entschärft
Eine Mock-Schnittstelle hilft, wenn ein fremder Service beim lokalen Entwickeln und Testen nicht verfügbar ist. Im selben Projekt lief ein Teil der Kommunikation über REST, etwa zu einem Service, der aus einer Vehicle Identification Number Fahrzeuginformationen wie den Hersteller zurückgab.
Lokal hatte man oft Zugriff auf diesen Service, aber nicht immer. Integrationsumgebungen sind dafür da, dass auch mal etwas deployt und ausprobiert wird. Fehlt der Service genau dann, wenn ein Prozess seinen REST-Aufruf braucht, steht man fest.
Die Lösung war ein Mock im eigenen Service, der das fremde System grob nachbildete. Keine echte Logik, etwas Zufall, aber Antworten, die plausibel genug aussahen. Für große Integrationstests reicht das nicht. Für lokales Durchtesten und für End-to-End-Tests reicht es, denn ein nicht verfügbarer Fremdservice ließ die eigenen Tests nicht mehr fehlschlagen.
Einfacheres Testen erzeugt bessere Qualität
Je leichter sich etwas testen lässt, desto mehr wird getestet. Die beschriebenen Maßnahmen zielen zunächst auf manuelles und teilautomatisiertes Testen, doch ihr Effekt geht weiter. Wer weniger Reibung beim Testen hat, testet häufiger und gründlicher. Daraus folgt direkt bessere Qualität.
Dasselbe Muster zeigt sich beim Dauerärger mit Testdaten und Umgebungen. Testdaten vorbereiten, Umgebungen aufbauen und wieder abräumen landet sonst immer bei irgendwem. Einmal sauber geskriptet oder hinter einer standardisierten Schnittstelle versteckt, fällt diese wiederkehrende Last weg.
Das Schönste daran ist, das ist absolut keine Rocket Science. Und das ist auch nicht viel Aufwand. Man braucht eigentlich nur die Ideen. Lars Luthmann
Wo du die Ideen findest
Die besten Kandidaten für Developer Friendliness liefert das Team selbst. Es sind die Aufgaben, bei denen Leute im Meeting mit den Augen rollen und denken “nicht schon wieder dieser Mist”. Genau dort lohnt sich der Eingriff.
Der Nebeneffekt geht über gesparte Zeit hinaus. Wer Entwickler, Tester und Analysten von nervigen Routineaufgaben befreit, schafft eine bessere Stimmung im Projekt. Und Menschen, die mit Freude arbeiten, bleiben eher. Team-Member-Friendliness ist damit auch ein Argument gegen Fluktuation, nicht nur eines für Effizienz.
