Warum Entwickler keine Stümper sind

Hartmut Schlosser

Projekte scheitern typischerweise nicht, weil es Programmierern an den nötigen fachlichen Kenntnissen fehlt – es ist der Kontext und die Umgebung, die Projekte typischerweise zum Scheitern bringen. Vor allem erschwert das Projekt-Management oft den Erfolg eines Projektes.

So lautet die Antwort von Stephan Schmidt, Berliner IT Manager und ehemaliger Team-Leiter bei ImmobilienScout24, auf Jared Richardsons vielbeachteten Blogeintrag: „You’re a Bad Programmer. Embrace It.„, in der auf polemische Art und Weise eine Haltung unter Entwicklern kritisiert wird, die Schuld für das eigene Scheitern bei anderen zu suchen.

Für Schmidt ist hingegen nicht ein zu hohes Maß an Eitelkeit unter Entwicklern das Problem, auch nicht die fehlende Einsicht, dass die eigenen Schwächen durch entsprechende Tools ausgeglichen werden müssen. Gerade gute Entwickler seien es, die einschätzen könnten, welche Werkzeuge sie tatsächlich effizienter werden lassen.

Good programmers use tools, from my experience, unit testsm static analysis, continous integration, bad ones don’t – they do not see the need and benefits of tool usage. Good programmers demand the introduction of tools. Stephan Schmidt

Das Scheitern von Projekten liegt Schmidts Erfahrung nach an anderen Problempunkten:

  • Falsche Arbeitslast-Einschätzungen: Meist werden solche Schätzungen nicht von den ausführenden Entwicklern, sondern von Projekt-Managern vorgenommen. Dabei sind die Arbeitseinheiten, die abgeschätzt werden sollen, typischerweise zu groß. Jede Arbeitseinheit, für deren Fertigstellung mit mehr als 1-3 Tagen zu rechnen ist, kann kaum realistisch eingeschätzt werden.
  • Falsche Status-Meldungen: Oftmals werden Arbeitseinheiten zu 80-90% für fertig gestellt erklärt (wobei sich die fehlenden 10-20% dann als besonders zeitintensiv erweisen). Folge ist ein trügerisches Gefühl des Fortschritts eines Projekts, das den Projekt-Manager lange in dem Glauben lässt, das Projekt sei auf einem guten Wege. Ein guter Projekt-Manager kennt nur drei verschiedene Status für Arbeitseinheiten: Todo, In Progress, Done.
  • Falsches Change-Management: Oft zu beobachten ist, dass einem Projekt ständig neue Features hinzugefügt werden, was zu unkontrollierbaren Veränderungen des Hauptfokus eines Projekts führt (Scope creep). Besser ist das Entfernen nicht mehr benötigter Features und das Ersetzen durch die aktuell gebrauchten.

All diese Probleme könnten nicht durch die Verbesserung der Programmierfähigkeiten eines Entwicklers, sondern durch agile Methoden wie Scrum gelöst werden.

You’ve guessed it, Scrum adresses all of these resulting in 99% – 100% on target delivery. So it’s not due to bad programmers if an agile process can fix this. Stephan Schmidt

Schmidts Fazit:

There are good and bad programmers. The good one are those who want to become better, are interested in their craft, the bad ones are those who do 9 to 5 jobs without any interest in their profession. Stephan Schmidt

Ein Plädoyer also für den engagierten Entwickler und ein Projekt-Management, das sich aktiv mittels agiler Methoden in den Entwicklungsprozess einklinkt.

Geschrieben von
Hartmut Schlosser
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.