Minimum Viable Programming

Ein Beispiel für einen solchen Fehler: Wenn ein Nutzer oder eine Nutzerin mehr als 50 Kontakte hatte, wurden nur die ersten 50 in der App angezeigt. Auf alle anderen konnte nicht zugegriffen werden. Es stellte sich heraus, dass eine unserer SaaS-Integrationen mit einer Paginierung arbeitete und die Entwickler Code implementiert hatten, bei dem nur die erste Seite der Ergebnisse angezeigt wurde.

Da dieser Fehler erst bei 51 Kontakten eines einzelnen Nutzers ausgelöst werden konnte und wir noch in der privaten Testphase waren, dauerte es eine Weile, bis wir darauf stießen. Als wir den Fehler gefunden hatten, meldeten wir ihn. Sie haben ihn sofort behoben. Wir testeten ihren Fix und er schien gut zu funktionieren.

Als ich mir den geänderten Code anschaute, wurde mir jedoch klar, wie unsauber ihre Lösung war. Anstatt eine While-Schleife zu verwenden, um alle Seiten zu laden, hatten sie einfach eine If-Bedingung hinzugefügt, um die zweite Seite zu laden. Sobald Nutzer mehr als 100 Kontakte hätten, wäre er der gleiche Fehler wieder aufgetaucht.

Den ersten Fehler hätte man als Versehen entschuldigen können. Der zweite war fahrlässig. Die Entwickler müssen sich gedacht haben, dass wir sehr lange brauchen würden, um die zweite Ergebnisseite auszugeben und noch länger für die dritte. Sie wussten, was sie taten, sie wussten um die Grenzen ihres "Fix", und sie taten es trotzdem. Wenn wir ihren Code nicht sorgfältig untersucht hätten, wäre dieser Fehler auch in die Produktion gelangt.

Keine Versionsgeschichte

Als Entwickler wusste ich aus eigener Erfahrung, wie nützlich eine Versionsgeschichte ist. Sie hilft zukünftigen Entwicklern zu verstehen, warum bestimmte Design-Entscheidungen getroffen wurden und wie bestimmte Funktionalitäten gebaut wurden. Außerdem bietet sie eine Vorlage für ähnliche Funktionen.

Während der Vertragsverhandlungen habe ich deswegen darauf bestanden, dass das endgültige Ergebnis ein Git-Repository sein sollte. Die Entwickler stimmten dem zu und sagten, dass sie auch intern Git verwenden. Als es an der Zeit war, uns den Quellcode zu liefern, schickten sie aber eine einzige Zip-Datei, die eine Mischung aus dem gesamten Quellcode und den generierten Dateien darstellte.

Ich erinnerte sie daran, dass sie sich vertraglich verpflichtet hatten, uns ein Git-Repository zur Verfügung zu stellen. Tatsächlich sah ich in der Zip-Datei, die sie uns geschickt hatten, sogar ein .git-Verzeichnis - was darauf hindeutet, dass sie Git für ihre Entwicklung verwendet hatten.

Am nächsten Tag schickten sie uns prompt ein Git-Repository. Es enthielt ein einziges Commit - das aus genau der gleichen Zip-Datei bestand, die wir am Tag zuvor erhalten hatten.

Ich schluckte meinen Ärger darüber herunter und sagte ihnen, dass wir die gesamte Versionsgeschichte haben wollten, nicht nur einen einzigen Commit, der die gleiche Zip-Datei enthielt. Sie antworteten, dass sie einige "sensible Informationen" in ihrem Git-Repository hätten, die nicht für ein externes Publikum bestimmt seien. Daher könnten sie diese nicht mit uns teilen. "Der Vertrag sagt nur, dass wir ein Git-Repository liefern sollen. Er sagt nicht, dass das Repository alle Entwicklungs-Commits und die Versionsgeschichte enthalten soll."