Developer Friendliness, oft als Teil der Developer Experience verstanden, 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 für die Developer Experience 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.
Auf 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 Akzeptanztests: 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, steckt 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.
Häufig gestellte Fragen
Worin unterscheidet sich Developer Friendliness von User Friendliness?
User Friendliness landet sichtbar im Endprodukt: bedienbare Oberflächen, Barrierefreiheit, schnelle Antwortzeiten. Developer Friendliness dagegen verlässt nie die Projektumgebung. Test-Schnittstellen, Mocks oder automatisierte Resets von Testumgebungen sind kein Teil der Auslieferung, sie unterstützen die Menschen, die das Produkt bauen. Genau dieser fehlende Produktbezug macht die Argumentation dafür schwieriger.
Wie viel Aufwand kosten interne Hilfsmittel für Entwicklung und Test?
Der Aufwand liegt je nach Maßnahme zwischen einem halben Tag und zwei bis drei Wochen. Diese Zeit fällt einmalig an, die Ersparnis wiederholt sich bei jeder Nutzung. Selbst wenn die Rechnung nur auf plus minus null aufgeht, bleibt ein Gewinn: Die Beteiligten sind die wiederkehrende Handarbeit los.
Wann ist der richtige Zeitpunkt, eine solche Maßnahme vorzuschlagen?
Zu Projektbeginn. Wird der Aufwand von Anfang an bewusst eingeplant, lässt sich die langfristige Ersparnis sauber begründen, statt später gegen ein volles Backlog zu argumentieren. Das stärkste Argument gegenüber der Projektleitung ist der Zeitfaktor: kurzfristig etwas investieren, langfristig deutlich mehr sparen und damit Kapazität für anderes freibekommen.
Wie lassen sich Kafka-Consumer manuell testen, ohne Nachrichten direkt in ein Topic zu schreiben?
Über eine zusätzliche REST-Schnittstelle pro Consumer, die ausschließlich dem Testen dient. Die Daten werden intern exakt so verarbeitet, als kämen sie aus dem Kafka-Consumer, das System kann die Herkunft nicht unterscheiden. REST bietet sich an, weil das Tooling ausgereift und niedrigschwellig ist. Im beschriebenen Leasing-Projekt dauerte die erste Schnittstelle einen guten Tag, jede weitere rund eine halbe Stunde.
Lohnt sich eine Testschnittstelle, wenn sie nur einen einzigen Zweck erfüllt?
Selten. Der Wert entsteht, wenn dieselbe Maßnahme mehrere Anwendungsfälle abdeckt. Im Leasing-Projekt bediente eine REST-Schnittstelle End-to-End-Tests, teaminterne Abnahmetests auf einer Umgebung ohne Schreibzugriff auf die Kafka-Topics und systemübergreifende Testtermine. Wenn dort rund 30 Personen sitzen und zwei bis vier Wochen früher getestet werden kann, ist der Aufwand um ein Vielfaches wieder drin.
Wann reicht ein einfacher, selbstgebauter Mock eines fremden Services aus?
Für lokales Durchtesten und für End-to-End-Tests reicht er, für große Integrationstests nicht. Der Mock im Leasing-Projekt bildete ein fremdes System nur grob nach: keine echte Logik, etwas Zufall, aber plausible Antworten. Sein Zweck war, dass ein nicht verfügbarer Fremdservice die eigenen Tests nicht mehr fehlschlagen ließ.
Führt einfacheres Testen tatsächlich zu besserer Software?
Ja. Je weniger Reibung beim Testen entsteht, desto häufiger und gründlicher wird getestet, und daraus folgt bessere Qualität. Der Effekt beginnt beim manuellen und teilautomatisierten Testen, reicht aber weiter: Auch das Vorbereiten von Testdaten und das Auf- und Abbauen von Umgebungen fällt als wiederkehrende Last weg, sobald es einmal sauber geskriptet ist.
Woran erkennt man im Team, welche Aufgabe sich zuerst lohnt?
An den Reaktionen im Meeting. Die besten Kandidaten sind die Aufgaben, bei denen Leute mit den Augen rollen und denken “nicht schon wieder dieser Mist”. Wer solche Frustrationspunkte abbaut, spart nicht nur Zeit, sondern verbessert die Stimmung im Projekt. Menschen, die mit Freude arbeiten, bleiben eher, und damit wirkt die Maßnahme auch gegen Fluktuation.
