Wann ist das fertig? Entwickler unter Druck

Neben der Frage “Warum ist das so?” ist üblicherweise die meist verhasste Frage, die man einem Entwickler oder Entwicklerin stellen kann: “Wann ist das denn jetzt fertig?”.

Also, warum ist das so?

Jeder will irgendwann fertig werden. Jeder hat eine Deadline im Kopf. Das betrifft nicht nur Entwickler, sondern auch andere Gewerkschaften, wie z.B. den Spülmaschinenmonteur:innen. Der Kunde will etwas haben, und dabei gibt es neben den Kosten und dem Umfang des Projekts den dritten Faktor: Zeit.

Es gibt das sogenannte "magische Dreieck", bei dem die Qualität des Projekts nur dann zufriedenstellend ist, wenn einer der drei Faktoren nicht bestimmt werden muss. Aber das ist hier nicht Thema und das ist offensichtlich auch kein Dreieck. Sieht einfach nur schlau am Anfang des Artikels aus und verdeutlicht, dass man im Leben nicht alles haben kann.

Anders als bei Spülmaschinenmonteur:innen fühlt sich die Frage nach dem Wann bei Entwicklern aber immer aktiv/passiv aggressiv an. Bei der Formung der Antwort bilden sich spinnennetzartige Gedankenmuster im Kopf, bei denen versucht wird, alle Stolpersteine vorherzusehen und abzuschätzen, wo die Kacke am wenigsten dampfen könnte.

Warum ist das so?

Grundsätzlich sollte eines vorweg genommen werden: Niemand kann sich wirklich in den Beruf des anderen reindenken und die Probleme verstehen, solange man es nicht selbst ausprobiert hat. Also versuchen wir mal, den Alltag eines Entwicklers in Methaphern zu schmücken.

Entwickeln ist wie Handwerk.

Man hat seine Werkzeuge, die man regelmäßig benutzt, um Dinge zu bauen. Genau, wie eine Tischlerin ihren Hammer, ihre Nägel und ihre Säge zur Verfügung hat. Fragt man eine Tischlerin: "Wann ist denn der Sarg fertig?", kann sie das relativ gut beantworten.

Sie weiß genau, wie der Sarg aussehen muss, weil der Kunde sich einen ausgesucht hat. Sie hat den Sarg schon oft zusammengebaut. Sie weiß, dass ihr geliebter Hammer auch den letzten Sargnagel einschlagen wird.

Der Entwickler hat auch seine Werkzeuge. Neben Dingen, die man anfassen kann, wie z.B. Tastatur oder Gehirn (sollte man nicht anfassen), gehören dazu Programme, eine sogenannte Entwicklungsumgebung und weitere Software-Teile, die meist aus der Open-Source-Welt stammen und von anderen Entwickler:innen kostenlos zur Verfügung gestellt werden.

Das Problem: Diese Werkzeuge entwickeln sich ständig, fast täglich weiter. Sie bekommen neue Funktionen, werden performanter oder haben plötzlich eine völlig andere Anwendungsweise.

Während die Tischlerin also mit ihrem 10 Jahre alten Hammer hämmert, wundert sie sich, warum sie keine Kunden mehr hat. Ihre Konkurrentin benutzt eine neue Hammer-Version ("MC Hammer"), mit dem die Arbeit viel leichter, somit günstiger ist und mit dem man sehr viel schönere Särge machen kann, weil keine Nägel mehr sichtbar sind.

Achja, außerdem hat ihr alter Hammer einen Fehler und alle Nägel, die sie hämmert, fallen beim Ablassen des Sargs raus, wenn ein bestimmtes Holz verwendet wird. Uncool.

Also kauft sie sich einen Neuen. Den muss sie sich an den Arm binden. Das macht den Arbeitsablauf performanter, denn das Suchen nach dem Hammer entfällt. Blöd nur: Jetzt kann sie ihre Säge nicht mehr bedienen, weil der Hammer im Weg ist. Glücklicherweise gibt es ein neues Modell der Säge, das dies berücksichtigt...

Entwickler:innen versuchen jeden Tag, mit der Technologie Schritt zu halten. Das fällt nicht nur schwer, weil man selbst älter wird und vergisst, was man zum Frühstück hatte, sondern auch, weil es immer mehr heißen Scheiß gibt, von dem man gehört haben muss. Der Druck wächst: Bleibt man bei dem, was man kennt oder wagt man den Blick über den Tellerrand? Kann man es sich leisten, 500 Stunden in das Lernen einer neuen Technologie zu stecken und ist man sich sicher, dass diese Technologie auch länger bestehen bleibt?

Die Wahl des Werkzeugs bringt eine große Portion Unschärfe in der Abschätzung der Timeline: Wie gut kennt man es? Benötigt der Kunde etwas Klassisches, Modernes oder Ausgefallenes? Letzteres macht das Ratespiel größer.

Entwickeln ist wie Rätselraten.

Särge bauen ist harte körperliche Arbeit, bei der man schwitzt. Beim Entwickeln schwitzt man eher im Kopf. Jede Entwicklung besteht aus Rätseln, die in der Schwierigkeit variieren.

Während der Programmierung versucht man, mehrere davon parallel zu lösen. Je komplexer das Thema, desto verworrener und zahlreicher sind sie. Auch die Art der Rätsel variiert. Manchmal ist es ein Sudoku, manchmal ein Wimmelbild, manchmal die Lösung der Unvereinbarkeit von Quantenmechanik und Allgemeiner Relativitätstheorie.

Am ehesten kann man sich den Alltag eines Entwicklers wie das eines rüstigen Rentners am Morgen vorstellen: Mit dem Bleistift in der einen Hand, den Kaffee in der anderen und dem Kreuzworträtsel der aktuellen Tageszeitung auf dem Tisch. Nur, dass man es 4-12 Stunden durchgehend macht und nebenher nicht nur die Zeitung, sondern auch alle Rätselhefte vom Kiosk nebenan bearbeitet.

Viele Rätsel kennt und hat man bereits gelöst. Aber es kommen auch neue hinzu. Man muss erst verstehen, wie sie funktionieren, um abschätzen zu können, wie lange man dazu braucht. Wenn der Kunde aber selbst nicht weiß, was es für ein Rätsel ist, gibt es das nächste Problem.

Entwickeln ist wie Formel 1

Alles, was man in der Formel 1 sieht, ist der Rennwagen und seine Schnelligkeit. Aber das, was den Kern ausmacht, ist unsichtbar: der Motor, die Entwicklung des Chassis und viele weitere technische Einzelheiten, von denen der Zuschauer selbst noch nie gehört hat.

Es werden Trilliarden von Entenhausen-Talern investiert, um die Autos schneller zu machen. Und was gibt den Ausschlag? Eine kleine Veränderung der Oberfläche. "Wir haben das Teil da hinten runder gemacht", sagt der Mechaniker. Dass es aber sehr viele Versuche und unendlich viel Zeit verschlungen hat, herauszufinden, dass das Teil da hinten runder sein muss, sieht niemand. Trotzdem ist es nötig.

Entwickeln ist ein Prozess.

Um bei der Analogie mit den Rätseln zu bleiben, im Folgenden ein reales Gespräch um 10:58 Uhr:

Kunde: "Ich habe hier ein Rätsel, wie lange brauchst du, um das zu lösen?"
Entwicklerin: "Was für ein Rätsel ist es?"
Kunde: "Keine Ahnung. Was mit Zahlen."
Entwicklerin: "Wenn es ein Sudoku mit 9 mal 9 Feldern in einer einfachen Variante ist, dann ungefähr 2 Minuten."

Ergebnis des Gesprächs: Der Kunde legt die Deadline auf 11 Uhr fest.

Selten weiß der Kunde, der Auftraggeber oder die Projektleiterin überhaupt, was er/sie will. Und das ist gar nicht schlimm! Es fängt nämlich immer mit einer einfachen Idee an:

• "Wir sollten eine neue Webseite bauen."
• "Der Benutzer soll direkt online bezahlen können."
• "Wir brauchen eine App, die genau trackt, wo man seine Spaziergänge macht, damit man keinen Weg doppelt läuft." (*)

Die Kernfrage ist, wann man damit zum "Entwickler" geht. Ist er einfach nur ausführendes technisches Organ, das einen Plan abarbeitet oder hilft er dabei, die Funktionsweise zu entwickeln? Letzteres ist nämlich ein Großteil der Arbeit. Jede Entscheidung über einen Weg, den man begehen möchte, führt dazu, dass es weitere Wege gibt, die bedacht werden müssen und nicht unbedingt etwas mit der Programmierung zu tun haben. So viele Rattenschwänze!

That's what she said.

Selbst bei eigenen Projekten muss ich mir immer wieder die Frage stellen: "Was will ich überhaupt?". Das ist normal. Die Entwicklung beginnt nämlich nicht mit der Programmierung, sondern mit dem Ablauf und den Funktionen. Erst wenn man sich sicher ist, was man möchte, beginnt man mit dem Hacken...

...nur um dann wieder alles umzuwerfen und neu zu machen. Auch das ist normal.

Entwickeln frustriert.

Die Zeitabschätzung wäre sehr viel einfacher, wenn es keine Stolpersteine geben würde. Solche Unvorhergesehenheiten können technischer, aber auch funktioneller Natur sein.

Man kann es sich ungefähr so vorstellen, dass plötzlich der Bohrer nicht mehr funktioniert. Der ging aber gerade noch. Also prüft man den Strom. Der geht. Ist der Bohrer kaputt? Nein, wenn man ihn auf den Kopf dreht, funktioniert er. Solche Dinge, die plötzlich und unerwartet kommen, benötigen Pufferzeit, die man vorher auch einberechnet haben sollte. Eine Programmierung basiert auf zahlreichen kleinen Einzelteilen, die alle ihre Macken und Eigenheiten haben können. Man könnte fast sagen, es wäre Stolperkies.

Wann ist es denn jetzt fertig?

"Fertig" ist in der Technik nie etwas. Alles wird weiterentwickelt. Es gibt immer neue Ideen und Innovationen. Sag das aber niemals einem Nicht-Techniker, das wird nämlich falsch interpretiert und du musst es dir jahrelang anhören.

Im Grunde ist es ganz einfach: Fertig ist es, sobald der Erste glücklich damit ist. Das heißt aber nicht, dass es für den Zweiten fertig ist. Für diesen ist es erst vollständig, wenn dessen Anforderungen erfüllt sind.

"Fertig" ist tatsächlich ein fließender Begriff, solange er nicht punktgenau definiert wird - und das ist er in den seltensten Fällen.

(*) Diese App-Idee stelle ich zur freien Verfügung. Mache deinen Sonntagsspaziergang, aber immer da, wo du noch nicht warst! Erkunde deine Umgebung, es gibt immer neue Ecken zu entdecken!