Programmierer sind nicht faul – sie sind nur die schlechtesten Schätzer der Welt

Judith Lungstraß

Wenn ein Programmierer abschätzt, wie lange er für eine Aufgabe brauchen wird, sollte man ihn in keinem Falle auf seine Aussage festnageln. Doch das liegt nicht daran, dass er sich selbst überschätzt, allzu optimistisch oder eventuell sogar faul ist. Nein, Programmierer sind ganz einfach die schlechtesten Schätzer der Welt.

Dieser Meinung ist zumindest Anders Abel, Autor des Blogs Passion for Coding. Die Fehlerrate einer Programmierer-Schätzung ist sogar so vorhersehbar, dass man sie auf eine mathematische Formel reduzieren kann, meint er. Man müsse dazu nur die geschätzte Zeit des Entwicklers nehmen, mit Pi multiplizieren und anschließend in die nächsthöhere Zeiteinheit umrechnen, um die tatsächlich benötigte Zeit heraus zu bekommen. Dieser Rechnung zufolge werden aus einem geschätzten Tag ganze 3,14 Wochen.

Da fragt man sich doch: Was verzögert die Arbeit eines Entwicklers so sehr, dass er es selbst nicht einmal bemerkt, geschweige denn mit einplanen kann. Abel listet eine Vielzahl an Hindernissen beim Erreichen der Dealine auf. Dazu zählen kleine Hürden wie das reine Starten des Computers oder das Auffinden der richtigen Informationen. Aber auch größere Hindernisse können sich dem Programmierer in den Weg stellen: Irgendwas geht immer schief, und besonders umfangreichere Aufgaben sind meist nur schwer einzuschätzen.

Doch richtiges Schätzen kann man lernen, glaubt zumindest Abel. So habe jeder Entwickler eine bestimmte Zeitspanne, die er realistisch abschätzen kann – bei erfahrenen Entwicklern ist das eine Spanne von einer halben bis hin zu 25 Stunden. Um das Schätz-Vermögen zu trainieren, solle man vor jeder Aufgabe schätzen, wie lange man für sie brauchen könnte, und nach Abschluss des Projektes notieren, wie viel Zeit es tatsächlich in Anspruch genommen hat. So lernt man die eigene Arbeitsweise und auch seine Wahrnehmung derselben besser kennen; bis hin zu dem Punkt, da sich Arbeitszeit und Wahrnehmung tatsächlich irgendwann decken.

Geschrieben von
Judith Lungstraß
Kommentare

4
Hinterlasse einen Kommentar

avatar
4000
4 Kommentar Themen
0 Themen Antworten
0 Follower
 
Kommentar, auf das am meisten reagiert wurde
Beliebtestes Kommentar Thema
2 Kommentatoren
Paul BommelAlmirEstigy Letzte Kommentartoren
  Subscribe  
Benachrichtige mich zu:
Estigy
Gast
Estigy

Kompletter Unsinn:
Zuerst sagt der Autor, die Fehlerrate ist so konstant, dass man eine einfache Formel dafür benutzen kann.
Dann sagt der Autor, die Fehlerrate ist auf 0 minimierbar.

Und woher weiß man dann, wo zwischen dem Asugangswert und Null man sich gerade befindet?

Almir
Gast
Almir

„Dieser Rechnung zufolge werden aus einem geschätzten Tag ganze 3,14 Wochen.“

Echt? Wenn ein Entwickler die Aufgabe so schlecht schätzen kann, dann ist er kein Entwickler. Meine Erfahrung: gute Entwickler schätzen die Aufgaben zu 90% korrekt.
Schlechte verschätzen sich ständig. Solche Entwickler muss man rechtzeitig durch „gute“ ersetzen.

Paul Bommel
Gast
Paul Bommel

@Almir: Füjhre Buch über deine Schätzungen und kontrolliere die. In einem halben Jahr sprechen wir uns dann wieder. Entweder du zieht bis dahin die Konsequenzen und kündigst selbst um Platz für einen „guten“ freizmachen oder du revidierst dein Statement.

Ich glaube, die Prozentzahl an Entwicklern, deren Schätz-Streuung um den tatsächlichen Wert vernachlässigbar klein ist wie du behauptest, geht gegen Null. Myself included, und ich habe > 20 Jahre Erfahrung als SW-Entwickler in allen möglichen Projekten.

Paul Bommel
Gast
Paul Bommel

@Almir: Abgesehen davon: Wenn schlechtes Schätzen ein Grund sein soll, ansonsten hervorragenden Leuten zu kündigen, dann ist dein Team sicher sehr klein. Aber paßt schon, wir suchen gute Leute. Schick die halt einfach zu uns.