Schätzung eines Softwareentwicklers: Ich werde Gärtner

Inhaltsverzeichnis

Vergangene Woche ging es um die Frage, was Softwareentwicklung eigentlich ist: Kunst oder doch eher eine Ingenieurswissenschaft? Meine These war, dass Softwareentwicklung etwas von beidem hat, aber dass wir den künstlerischen Aspekt im Alltag zu oft vergessen und uns häufig gar nicht im Klaren darüber sind, wo wir selbst eigentlich auf dieser Skala stehen: Sind wir Künstler oder Ingenieure?

the next big thing – Golo Roden

Golo Roden ist Gründer und CTO von the native web GmbH. Er beschäftigt sich mit der Konzeption und Entwicklung von Web- und Cloud-Anwendungen sowie -APIs, mit einem Schwerpunkt auf Event-getriebenen und Service-basierten verteilten Architekturen. Sein Leitsatz lautet, dass Softwareentwicklung kein Selbstzweck ist, sondern immer einer zugrundeliegenden Fachlichkeit folgen muss.

Zu diesem Blogpost gab es zahlreiche Kommentare, nicht nur hier im Developer-Kanal, sondern auch unter dem zugehörigen Video auf YouTube. Ein Kommentar ist mir dabei besonders aufgefallen: Der Verfasser stimmte meiner Aussage grundsätzlich zu, sah aber einen Punkt anders. Ich hatte nämlich erwähnt, Kunst sei nicht schätzbar, doch seiner Meinung nach könne man alles schätzen: Entwicklerinnen und Entwickler hätten nur zu oft Angst, bei Unsicherheiten oder Unwissen einfach eine große Zahl zu nennen.

Ein Space-Shuttle schätzen

Das hat mich nachdenklich gestimmt, denn wenn ich unsicher bin oder mir grundlegendes Wissen fehlt, dann kann ich nicht deshalb nicht schätzen, weil ich mich nicht traue, eine große Zahl zu nennen. Das Schätzen ist vielmehr unmöglich. Würde ich in einer solchen Situation einfach eine große Zahl nennen, dann wäre das nicht geschätzt, sondern einfach nur geraten.

Empfohlener redaktioneller Inhalt

Mit Ihrer Zustimmmung wird hier ein externes YouTube-Video (Google Ireland Limited) geladen.

YouTube-Video immer laden YouTube-Video jetzt laden

Ich bin damit einverstanden, dass mir externe Inhalte angezeigt werden. Damit können personenbezogene Daten an Drittplattformen (Google Ireland Limited) übermittelt werden. Mehr dazu in unserer Datenschutzerklärung.

Wenn Sie mich fragen, wie lange ich persönlich brauche, um ein Space-Shuttle von Grund aufzubauen, dann habe ich absolut keine Ahnung, was ich antworten soll. Dabei hilft mir auch nicht der Mut, eine große Zahl zu äußern, denn das macht die Schätzung nicht solider: Ob ich nun fünf, zehn oder zwanzig Jahre sage – alles hat die gleiche Aussagekraft, nämlich praktisch gar keine. Und deshalb ist es meiner Meinung nach auch keine Schätzung, sondern wie gesagt nur (schlecht) geraten.

Trotzdem hat mich diese Frage nicht losgelassen, und ein befreundeter Unternehmer hat mich vor ein paar Tagen auf den sehr spannenden Blogpost "Are you a Software Gardener?" von Chris Aitchison aufmerksam gemacht. Seine Kernaussage ist, dass wir als Entwicklerinnen und Entwickler keine Ingenieure seien, sondern viel eher Gärtner.

Die Softwareentwicklung als Gartenpflege

Als ich diesen Vergleich zum ersten Mal gelesen habe, fand ich ihn zugegebenermaßen doch ein wenig schräg, aber der Blogpost kommt auf einen sehr guten Punkt zu sprechen: Darin heißt es nämlich, dass Ingenieursprojekte im Wesentlichen vorhersagbar seien und dass es deshalb möglich sei, die Planung und auch den Bau zum Beispiel einer Brücke oder eines Wolkenkratzers zeitlich recht genau vorherzusagen. Denn wie man eine Brücke oder einen Wolkenkratzer baut, sei inzwischen hinreichend bekannt, und unterscheide sich nicht allzu sehr von Instanz zu Instanz und sei außerdem in den meisten Fällen unabhängig von der jeweiligen Umgebung. Natürlich gibt es Unterschiede im Preis, aber das Grundprinzip, wie eine Brücke oder ein Wolkenkratzer gebaut wird, sei im Großen und Ganzen eben immer dasselbe.

Ganz anders sehe es hingegen aus, wenn man einen Garten anlegen möchte. Natürlich hätte man auch dann einen groben Plan und könne sagen, wo welcher Baum, welcher Strauch, welche Blumen und so weiter gepflanzt werden sollen. Aber anders als bei einem Bauwerk, bei dem man in der Regel im Vorfeld schon sehr genau wisse, wo welcher Stein oder welcher Träger zum Einsatz kommen werde, könne man bei einem Garten eben nicht jedes einzelne Blatt oder jede einzelne Blüte im Detail vorhersagen. Und es sei doch auch ziemlich abstrus, wenn man das versuchen würde.

Tatsächlich dürfte auf der Hand liegen, dass nicht vorhersagbar ist, wie viele Blüten ein paar heute gepflanzte Narzissenzwiebeln im kommenden Frühjahr haben werden. Je nach Wetter, Klima, Bodenbeschaffenheit und so weiter kann man noch nicht einmal genau vorhersagen, ob sie überhaupt den nächsten Winter überleben werden. Natürlich hat man als erfahrene Gärtnerin oder als erfahrener Gärtner hier ein gewisses Gefühl und eine gewisse Erfahrung, aber garantieren kann man es eben nicht.

Proaktive Pflege

Und genauso verhält es sich auch bei Software: Auch Software ist einzigartig und hängt maßgeblich von ihrer jeweiligen Umgebung ab. Außerdem ist Software nie fertig, sondern es lässt sich immer noch etwas daran weiterentwickeln, genauso wie man auch in einem Garten niemals fertig sein wird. Das liegt allein schon daran, dass sich die Umgebung wandelt: Die Hardware verändert sich, das zugrunde liegende Betriebssystem ändert sich, Bibliotheken und APIs wandeln sich, und so weiter.

All diesem Wandel muss ich mit meiner Software im Laufe der Zeit immer wieder Rechnung tragen. Klar: Software altert per se nicht, aber sie wird eben eher selten heute noch unter den gleichen Bedingungen ausgeführt wie vor fünf oder zehn Jahren. Damit das funktioniert, muss man proaktiv etwas dafür machen.

Erfahrung erkennen

Das funktioniert natürlich dann deutlich besser, wenn die Gärtnerinnen und Gärtner der Software (also die Entwicklerinnen und Entwickler) eine gewisse Erfahrung mitbringen, ihre Werkzeuge kennen und ein Händchen für geschickte Softwareentwicklung haben. Genauso wie man bei Pflanzen davon spricht, dass jemand einen "grünen Daumen" habe, gibt es auch in der Softwareentwicklung Menschen, die ein besseres Geschick bei der Gestaltung von Algorithmen und Datenstrukturen haben als andere.

Diese Fähigkeit lässt sich nicht gut quantifizieren, es gibt keine besonders geeignete Metrik dafür. Aber erfahrene und geschickte Entwicklerinnen und Entwickler erkennen ihresgleichen innerhalb kürzester Zeit aus dem Gefühl heraus. Anders formuliert: Wer selbst nicht Software entwickelt, wird es schwer haben, die wirklich guten Entwicklerinnen und Entwickler zu identifizieren. Oft entscheidet dabei dann letztlich das Bauchgefühl, gefolgt von der Hoffnung, dass die Entscheidung nicht katastrophal schlecht war.

Übrigens, wenn Ihnen die Metapher mit dem Garten nicht zusagt, gibt es noch andere vergleichbare Disziplinen, wie zum Beispiel das Kochen oder das Spielen eines Instruments. Auch diese beiden Beispiele erfordern den Einsatz von Technik, aber beides geht, wenn es wirklich gut werden soll, weit über reine Technik hinaus. Das Beherrschen der Technik ist also eine notwendige, aber keine hinreichende Vorbedingung.

Meine Schätzung? Maximal 1 Milliarde Euro …

Deshalb, und damit komme ich auf den ursprünglichen Punkt zurück, ist das Schätzen in der Softwareentwicklung meiner Meinung nach kaum sinnvoll.

Klar, wenn Sie mich fragen, wie lange ich brauche, um in Go einen Webserver zu schreiben, der ein paar API-Routen anbietet, die mit einer Datenbank kommunizieren und JSON zurückgeben oder entgegennehmen, dann kann ich Ihnen das ungefähr beantworten, weil ich das schon etliche Male gemacht habe. Aber selbst bei diesem trivialen Beispiel gibt es Unsicherheiten, die einen massiven Einfluss haben können:

• Verfügt die API über eine Authentifizierung?
• Wird die API CORS unterstützen?
• Wie sieht die Test-Strategie für die API aus?
• Wird eine Dokumentation für die API benötigt?
• Wird die API versioniert, und wenn ja, nach welchem Schema?
• Gibt es Besonderheiten bezüglich Caches oder Proxies zu beachten?
• …

Je nachdem, wie diese Fragen beantwortet werden, reden wir unter Umständen über Schwankungen in der Schätzung von mehreren hundert, wenn nicht gar tausend Prozent. Und das wohlgemerkt bei einem grundsätzlich bekannten Problem!

Wenn ich nun aber schon das nicht exakt vorhersagen kann, ohne zunächst alle möglichen Details im Vorfeld durchzusprechen, wie soll ich dann eine Aufwandsschätzung für etwas geben, was ich fachlich und inhaltlich noch nie gemacht habe, was für mich also komplett unbekanntes Terrain ist?

Natürlich kann ich dann den ursprünglichen Hinweis aus dem Kommentar nehmen und sagen: "Na ja, also mehr als eine Milliarde Euro wird’s wohl nicht kosten". Und höchstwahrscheinlich werde ich mit dieser Einschätzung sogar auch richtig liegen – nur nützt die eben niemandem etwas.

Der Weg zu einer fundierten Schätzung

Die Frage ist, was man daraus macht. Denn das Business möchte manchmal einfach Zahlen haben, um abschätzen zu können, ob sich eine Entwicklung überhaupt rentiert und ob sich der Aufwand am Ende voraussichtlich lohnen wird. Und auch, wenn es aus unserer Sicht als Entwicklerinnen und Entwickler oftmals nicht möglich ist, eine sinnvolle Schätzung abzugeben, heißt das nicht, dass die Frage nach der Schätzung nicht grundsätzlich berechtigt wäre. Sich einfach nur hinzustellen und zu sagen "sorry, das kann ich nicht schätzen" nützt wenig und bringt niemandem das eigentliche Ziel näher.

Deshalb glaube ich (und das ist auch das Verfahren, das wir in meinem Unternehmen the native web anwenden): Wenn wir etwas nicht schätzen können, weil es zu viele Unbekannte gibt, muss dem Entwicklungs- zunächst ein Forschungsprojekt vorangestellt werden, in dem man die wichtigsten Probleme zu lösen versucht. Das Ziel ist also zunächst, einen "Proof of Concept" zu entwickeln, einen "Durchstich", einen "Prototypen", oder wie auch immer man das Ganze nennen will. Dabei geht es jedoch zunächst nur darum, mehr Wissen zu erlangen und erste Erfahrungen zu sammeln, um sich selbst in eine bessere Ausgangslage für eine vernünftige Schätzung zu bringen.

Und diese Forschung, die wird nicht geschätzt, sondern durch eine Timebox begrenzt. Man nimmt sich zum Beispiel vier Wochen Zeit, um herauszufinden, wie bestimmte Dinge funktionieren, ob sie überhaupt funktionieren, und so weiter. Was diese vier Wochen kosten werden, ist vorher bekannt, denn sie können nach zeitlichem Aufwand abgerechnet werden. Und danach schaut man sich das Ergebnis an: Wenn es vielversprechend ist, macht man weiter und kommt einer verlässlichen Schätzung auf dem Weg nach und nach näher. Wenn das Ergebnis jedoch nicht vielversprechend ist, kann man sich entscheiden, ob man weiter forschen und noch einmal in eine Timebox investieren möchte, oder ob man es lieber bleiben lässt.

Hand in Hand mit dem Business

Das ist meines Erachtens der deutlich bessere Weg, als einfach irgendeine große Zahl zu sagen, um eine Zahl gesagt zu haben. Natürlich muss auch das Business am Ende des Tages mitspielen. Aber ich glaube, dass man gut vermitteln kann, dass wenn eine Schätzung benötigt wird, man dann auch zunächst eine vernünftige Grundlage schaffen muss, auf deren Basis man eine solide Schätzung überhaupt durchführen kann.

Meine Erfahrung ist, dass man das verständlich erklären kann und das Business es häufig sogar zu schätzen weiß, wenn man das offen und transparent kommuniziert. Denn das zeigt, dass man gerade nicht einfach irgendetwas sagt, sondern dass man die Anfrage ernst nimmt, dass man vertrauenswürdig ist, und dass man versucht, das Problem konstruktiv und vor allem gemeinsam anzugehen. Und das ist es, worauf es letztlich in der Softwareentwicklung ohnehin ankommt: Dass alle Beteiligten gemeinsam an einem Strang ziehen. Warum also damit nicht schon bei der Aufwandsschätzung starten? (rme)