Was ist Developer Experience?
Was verstehen wir bei triplecore unter Developer Experience und warum finden wir, dass eine gute Developer Experience den Erfolg von Softwareentwicklung insgesamt verbessern kann?
Developer Experience (DX) wird oft mit User Experience (UX) verglichen. Wir finden, dass das eine gute Analogie ist. Es lassen sich die gleichen Kriterien für User Experience und Developer Experience anwenden. Bei Entwicklern stehen ihre Werkzeuge, also zum Beispiel Entwicklungsumgebungen, Programmierschnittstellen zu anderen Systemen, Build-Prozesse zum Bauen der Werkzeuge oder die Methodik der Produktentwicklung im Vordergrund.
- Funktion: hilft mir das Werkzeug bei meiner Arbeit?
- Stabilität: kann ich mich auf die Ergebnisse meiner Nutzung des Werkzeugs verlassen?
- Einfachheit: ist das Werkzeug dem Anwendungsfall entsprechend einfach zu benutzen?
- Klarheit: ist der Arbeitsweise des Werkzeugs nachvollziehbar, das betrifft sowohl die Voraussetzungen für den Einsatz als auch die "inneren" Methoden.
Für eine gute User Experience ist es notwendig, den Nutzer der Software zu kennen. Genauso wichtig ist es, den Entwickler und die Entwicklerin für eine gute Developer Experience zu kennen.
Wir denken auch, dass man den Vergleich von DX und UX noch weiter ziehen kann. Wer versteht, wie Entwickler denken und arbeiten und entsprechende Rahmenbedingungen schafft, erhöht die Zufriedenheit im Team, vergrößert die Identifikation des Teams mit dem Produkt, verbessert die Qualität der Softwareentwicklung und trägt damit zum Erfolg des Geschäftes bei.
Developer Experience bei externen APIs
In vielen Blog-Artikeln wird Developer Experience insbesondere für externe APIs betrachtet. APIs sind Programmierschnittstellen zu anderen Systemen, die Entwickler nutzen, um ihr Produkt um Features zu erweitern, die sie selbst nicht programmieren müssen. APIs gibt es für viele Funktionen, von der einfachen Prüfung einer europäischen Umsatzsteuer-ID bei der EU bis zur Schnittstellen zur Künstlichen Intelligenz, die den Inhalt von Fotos erkennt. Viele Unternehmen, deren Geschäft auf der Bereitstellung von solchen APIs für beruht, haben Verantwortliche oder ganze Abteilungen für Developer Experience, die sich um das Wohlbefinden der der Programmierer, die die API nutzen, kümmern.
Für APIs lassen sich einfache und nachvollziehbare Qualitätskriterien für eine gute Developer Experience identifizieren.
- Einfacher Zugang: Zugang zu einer API oder ihrer Dokumentation erst nach Anruf/Email/Online-Formular ist eine deutliche Einstiegshürde. Eine gut strukturierte und dokumentierte API lässt die Möglichkeiten (und die Grenzen) einer Schnittstelle schnell verstehen. Im Kopf der Entwicklerin entsteht ein klares Bild über den Nutzen der API für die eigenen Ziele.
- Ausprobieren: Lässt sich das API einfach ausprobieren, zum Beispiel in einer Sandbox, wird das mentale Bild klarer und detaillierter.
- Schneller Start: Eine flache Lernkurve zu Beginn der Nutzung hilft, mit den Kern-Konzepten des API schnell vertraut zu werden. "Hello World" sollte in kurzer Zeit funktionieren. Einfache Dinge sollten schnell verständlich sein.
- Gute Beispiele: Beispiel-Code, am besten per Copy&Paste in die Konsole oder den Editor zu übernehmen, erhöht den Wert der Dokumentation. Tutorials für nützliche Use Cases sind oft der erste Schritt zur Integration des API in die eigene Applikation.
Darüber hinaus gibt es weitere Faktoren, die via Developer Experience über den Erfolg einer API entscheiden. Entwicklerinnen sind offen für neue Ideen, möchten aber vorhandenen, getesteten und lauffähigen Code nicht gern wegwerfen. Eine API mit guter DX macht es möglich, von neuen Dingen zu profitieren, ohne alles neu entwickeln zu müssen. Grundlegende Änderungen der Architektur und Inkompatibilitäten zwischen API-Versionen verschlechtern die DX und sollten daher gut überlegt und begründet sein. Die Änderungen müssen deutliche Vorteile bringen.
Kostenpflichtigen APIs hilft ein klares Preismodell. Gibt es eine kostenfreie Basisversion? Welche Faktoren wie zum Beispiel API-Aufrufe, Datenmengen oder ähnlich haben Einfluss auf den Preis? Welche Staffelungen gibt es?
In der Produktentwicklung haben sich Personas zur Dokumentation von Benutzeranforderungen etabliert. Externe APIs sind Produkte deren Nutzer Entwickler sind. Es ist sinnvoll, Entwickler-Personas beim Design von APIs zu definieren und in der Entwicklung immer wieder zu nutzen
Das lokale Entwicklungsteam und DevEx
Auch Entwickler-Teams selbst können für gute Developer Experience sorgen. Als erstes gilt natürlich das gleiche wie für externe APIs: interne Schnittstellen sollten einfach zugänglich sein, sollten sich ausprobieren lassen - mindestens auf Dev und Stage, die Lernkurve sollte zu Anfang flach sein, Dokumentation sollte vorhanden und mit guten Beispielen ausgestattet sein. All das wird intern weiter verbessert, wenn die Entwickler, die für das API verantwortlich sind, gut erreichbar und ansprechbar sind.
Eine gut entworfene und dokumentierte Architektur erleichtert den Überblick und lässt beim Abtauchen in die Details Zusammenhänge einfacher verstehen. Eine einfach zu nutzende Toolchain ermöglicht schnelle Erfolge bei der Umsetzung von Stories. Werden Frameworks mit guter Dokumentation und ausreichend großer Community genutzt, hilft das bei Einarbeitung und Fehlersuche. Eine überschaubare Auswahl von Sprachen und Entwicklungsumgebungen lässt die Entwicklerin sich auf die Programmierung fokussieren und hilft dabei, sich nicht durch häufige Kontextwechsel ablenken zu lassen.
Die Qualität der lokalen DevEx lässt sich zum Beispiel in einer Team-Retrospektive eigenverantwortlich prüfen: Was muss ein neu ins Team gekommener Entwickler wissen, um produktiv werden zu können? Wie leicht lassen sich die Entwicklungswerkzeuge auf dem Rechner installieren? Welche Zugänge sind notwendig? Gibt es eine gut strukturierte Dokumentation für die Einarbeitung? Ist die Architektur-Übersicht aktuell? Sind die Entwicklungs-Flows selbsterklärend? Mit einer Sterne-Bewertung dieser und weiterer Punkte durch das Team lässt sich schnell Überblick gewinnen und Stories für Optimierungen ableiten.
Developer Experience und Produktentwicklung
Eine gute Developer Experience führt bei Entwicklern zu erhöhter Nutzung des Produktes, zu einer tieferen Identifikation und zu mehr Verantwortungsgefühl für ihr Produkt. Eine enge Zusammenarbeit zwischen Product Ownern, UX/UI-Designern und Entwicklern führt zu einer Verbesserung der Produkteigenschaften. Eine klare Zielorientierung, wie zum Beispiel an Nutzerzahlen, Kundenzufriedenheit oder erhöhter Effizienz wird auch von vielen Entwicklern als Motivation ihrer Arbeit gesehen. Die Produkt-Roadmap zeigt dem Entwicklungs-Team den Weg zu diesen Zielen.
Entwickler sind Menschen - weiche Faktoren von DevEx
Auch menschliche Faktoren spielen bei der Developer Experience eine wichtige Rolle. Entwickler sind häufig Menschen mit hoher Wertschätzung für gut gestaltete und umgesetzte Dinge. Oft bezieht sich das auf das äußere Erscheinungsbild, noch häufiger jedoch auf die innere Konstruktion.
Entwickler schätzen an ihrer Arbeit oft besonders die "Magie" beim Codieren, die Lösung von Logik-Rätseln durch eigenen Code. Gute Developer Experience verringert den Anteil der nicht-magischen Arbeit und verstärkt den Anteil im Flow. Auch Entwickler wollen Sinn in ihrer Arbeit sehen und Gutes tun. Sie haben meist wenig Interesse an politischen Streitigkeiten und schätzen eine positive, an Leistung orientierte Arbeitsatmosphäre. Entwickler geben ihr Wissen gern an andere weiter.
Vorteile einer guten Developer Experience
Teams mit guter DevEx sind zufriedener - das gilt zuallererst für die Entwickler als Hauptzielgruppe, überträgt sich dann auch auf Product Owner, Designer, Scrum-Master und Agile Coaches und andere Teammitglieder. Das Vertrauen zwischen Business und IT wird gestärkt. Entwickler nutzen ihr Produkt häufiger und promoten es mehr. Gute DevEx verringert Kopfmonopole und die "Nicht mein Problem"-Mentalität. Als sinnlos empfundene Arbeit wird weniger. Die Code-Qualität verbessert sich, die Entwicklungskosten sinken.