Nummer 2 der Sieben Dinge, die dein Chef nicht über Softwareentwicklung weiß ist laut John Sonmez die Aussage “Zeitabschätzungen sind im wesentlichen Bullshit”. Im Grunde ist das keine wirklich neue Erkenntnis. Wie so vieles haben wir alle wahrscheinlich schon öfter bemerkt, dass wir uns bei solchen Sachen gehörig verschätzt haben.
Das ist solange kein Problem, wie ich zunächst nur für mich selbst denke, “wie lange wird das wohl dauern”. Das kann ich aufschreiben und dann die Zeitmessung dagegen setzen, wie lange ich wirklich gebraucht habe. Vielleicht kann ich daraus etwas lernen. Bessere Zeitschätzungen machen vielleicht. Oder dass Zeitschätzungen eben Bullshit sind.
Warum ist das so? Denken wir mal darüber nach, was ein Programmierer machen sollte, wenn er seinen Job ernst nimmt. Das gilt natürlich auch für Programmiererinnen, aber ich halte nichts von dem sprachlichen Zwangsgenderismus. Ich meine also Programmierer allerlei Geschlechts: männlich, weiblich, Agender, Neutrinos, und wie sie alle heißen. Man verliert echt den Überblick; wie viel Geschlechter hatten wir noch im letzten Jahr?
Also nochmal zurück: Was macht ein Programmierer, der seinen Job ernst nimmt?
DRY
Richtig, das DRY-Prinzip. Ausgeschrieben heißt das “Don’t Repeat Yourself”. Ein Programmierer ist von Hause aus faul. Ich habe zwar in einem aktuellen Legacy-Projekt zahlreiche Stellen entdeckt, wo ich immer denke, “Oh Mann, die müssen damals nach Lines of Code bezahlt worden sein!”, aber eigentlich vermeidet man das. Und das aus gutem Grund, denn es ist auch gut für die Firma, wenn der Softwareentwickler faul ist. Warum? Das habe ich hier erklärt. Kurz gesagt hat das den Vorteil, dass eine einmal ausprogrammierte und getestete Funktion oder Klasse so oft wiederverwendet werden kann, wie es einem beliebt. Die Firma profitiert davon, weil sie für den Aufwand, diese Klasse erneut zu programmieren und zu testen, nicht nochmal bezahlen muss, denn die Klasse wird halt nicht neu programmiert.
In der Folge kann man davon ausgehen, dass alles, was ein Softwareentwickler macht, etwas neues ist. Jeder neue Programmteil ist wie ein Prototyp eines Fahrzeugentwicklers oder Maschinenbauers. Es handelt sich eben nicht um das digitale Pendant einer Fertigungsstraße, wo ein und das selbe Getriebe eine Million mal gebaut wird. Was bei Hardware leider nicht möglich ist, kann mit Software nahezu problemlos gemacht werden. Wenn man es richtig macht.
John empfiehlt, die Aufgabe herunterzubrechen, so dass keine größer als 4 Stunden ist. Dann, so sagt er, könnte die Zeitabschätzung funktionieren. Das ist übrigens etwas, bei dem uns das freie Programm ToDoList (leider nur für Windows) sehr gut unterstützen kann. Das hatte ich vor längerem mal kurz erwähnt. Vielleicht schreibe ich demnächst mal etwas mehr darüber.
Neueste Kommentare