Bewegliche Ziele

Während der Verhandlungen hatten wir mehrfach erwähnt, dass die serverseitigen APIs noch nicht vollständig implementiert sind und dass wir die Backend-Entwicklung parallel zur Frontend-Entwicklung machen wollten. Außerdem sagten wir, dass ich ihnen zu Beginn des Projekts alle API-Endpunkte zur Verfügung stellen würde, von denen einige vollständig implementiert wären. So konnten sie sofort mit der Arbeit an den einfacheren Funktionen beginnen und diese wenigen Endpunkte verwenden. Wenn sie die ersten Funktionen fertig hätten, wären die APIs bereit für die nächsten.

Unser Ziel war es, Verzögerungen zu vermeiden und parallel zu arbeiten, um so insgesamt früher mit der App starten zu können. Wir haben das immer wieder so gesagt - und uns wurde stets rückgemeldet, dass alles in Ordnung sei.

Sobald wir das Geld bezahlt hatten, änderte sich das aber. Plötzlich weigerten sich die Entwickler, überhaupt mit der Arbeit zu beginnen, bevor die Backend-Entwicklung zu 100 Prozent abgeschlossen war - und zwar für jede einzelne Funktion des gesamten Projekts.

Glücklicherweise war ich zu diesem Zeitpunkt mit der Backend-Entwicklung beinahe fertig, da wir viel Zeit mit Vertragsverhandlungen und Designarbeiten verbracht hatten. Also war das am Ende kein Problem. Aber ich war schockiert und sehr enttäuscht, dass sie die Versprechen, die ihre Vertriebsmitarbeiter zuvor gemacht hatten, nicht einhielten.

In den Vorgesprächen hatten sie quasi den roten Teppich für uns ausgerollt. Als es dann aber losging, gruben sie sich ein und bestanden darauf, dass alles ganz genau nach ihren Vorstellungen ablaufen sollte.

My Way oder Highway

Zum Beispiel verwendete ich, nach eingehender Prüfung aller Optionen, Swagger, um die API-Endpunkte, ihre Eingaben, Schemata, Beschreibungen und ihr Verhalten zu dokumentieren. So wurde die Dokumentation in den Code eingebettet, automatisch generiert und auf dem neuesten Stand gehalten. Die Swagger-GUI bietet außerdem die sehr angenehme Möglichkeit, alle API-Dokumentationen zu durchsuchen und sogar API-Aufrufe zu Testzwecken direkt von der GUI aus zu machen.

Leider hatte die Firma ein anderes Vorgehen. Die Entwickler weigerten sich also, Swagger als Dokumentationsquelle zu nehmen. Stattdessen bestanden sie darauf, dass wir ihnen ein Word-Dokument per E-Mail schickten, mit dem gleichen Inhalt wie dem in Swagger, aber mit ihren spezifischen Formatierungsanforderungen.

Wir diskutierten mehrere Tage lang, bevor sie schließlich nachgaben. Diese Einstellung zog sich jedoch durch den gesamten Entwicklungsprozess. Wir hatten die Entwickler beauftragt, mobile Apps unter Verwendung unserer Backend-APIs zu entwickeln. Sie waren aber sehr wählerisch, denn sie wollten, dass die APIs auf eine ganz bestimmte Weise funktionierten. Jedes Mal, wenn es eine philosophische Meinungsverschiedenheit über das API-Design gab, mussten wir ewig darüber debattieren.

Es ist möglich, dass all dies von ihrer Leidenschaft für API-Best-Practices rührte, aber ich vermute, dass es in erster Linie daran lag, dass sie ihre eigene Arbeit so unabhängig wie möglich machen wollten. Und an ihren Problemen, die benötigte Funktionalität mit einer bestehenden API zu implementieren.