Computerhaus Quickborn

Entwickler gehören nicht ans Fließband!​

Alles ganz modern? Everett Collection | shutterstock.com Seitdem im Jahr 1946 der Großrechner ENIAC an die US-Armee ausgeliefert wurde, ringen Unternehmen und Organisationen damit, die Softwareentwicklung effektiv zu managen. Das Problem ist aus dem militärischen Bereich bekannt: Bei der Vorbereitung auf künftige Konflikte wird vor allem über die bereits ausgetragenen nachgedacht. Das kann dazu führen, dass Technologien und Strategien angewendet werden, die in der Vergangenheit zwar effektiv waren – mit Blick auf die Zukunft allerdings nicht dasselbe versprechen. Früher wurden die Mitarbeiter in Fabriken dazu aufgefordert, die Stechuhr zu drücken – und von durch die Flure wandernden Managern kontrolliert. Das machte auch Sinn, wenn es beispielsweise darum ging, Verschlusskappen auf Rasierschaumdosen zu setzen. Die Leistung der Arbeiter war einfach zu erfassen, ihre Anzahl ein guter Erfolgsindikator: Je mehr Füße am Fließband standen, desto mehr wurde produziert. Leider wurde dieses Konzept auch für die Softwareentwicklung übernommen. Nur, dass Füße und Fließband dabei durch „Hintern“ und „Stühle“ ersetzt wurden. Mehr Hintern, mehr Software? Das ist umso erstaunlicher, weil die meisten nicht-technischen Führungskräfte gar nicht beurteilen können, was Developer eigentlich tun – geschweige denn, wie gut und ob das in angemessener Geschwindigkeit abläuft. Das macht es quasi unmöglich, die Produktivität einzelner Softwareentwickler zu messen. Die „Zauberformel“ vieler Manager scheint sich deshalb am Rasierschaumdosen-Beispiel zu orientieren: Je länger diese Menschen auf ihren Tastaturen herumhämmern, desto mehr muss am Ende auch produziert werden – was auch immer das genau sein mag. Mit Blick auf die Praxis zeigt sich, wie realitätsfern diese Sichtweise ist. Etwa, wenn ein Entwickler 1.300 Zeilen Spaghetti-Code eliminiert und sie durch 200 deutlich elegantere und effizientere Code-Zeilen ersetzt. Oder wenn Developer eine Woche damit verbringen, ein Projekt ordentlich aufzusetzen, um damit dem Team unzählige Arbeitsstunden zu sparen. Manager verspüren eben oft nur den Drang, etwas zu messen. Das ist in der Regel die für einen Task aufgewendete Zeit. Deswegen sind nicht wenige Dev-Teams dazu angehalten, die Zeit für jede einzelne Aufgabe wie etwa die Fehlerbehebung zu erfassen. Schlimmer wird es dann nur noch, wenn die erfassten Zeiten auch noch miteinander verglichen werden, um ein Maß für Produktivität und Erfolg zu bestimmen.    Die schlimmste Kennzahl überhaupt Eine minutiöse Zeiterfassung im Softwareentwicklungsumfeld ist aus verschiedenen Gründen kontraproduktiv: Geht es darum, Software zu schreiben, gleicht kein Fehler dem anderen. Unerfahrene Entwickler sind vielleicht in der Lage, schnell Lösungen für viele einfache Fehler zu finden. Erfahrenere Entwickler, die sich im Allgemeinen  anspruchsvolleren Problemen widmen, brauchen entsprechend länger. Und was, wenn einem Junior-Entwickler ein Fehler zugewiesen wird, den er nicht bewältigen kann? Die Zeit für einzelne Tasks erfassen zu müssen, könnte manche Devs dazu ermutigen, das System zu manipulieren. Das führt dann dazu, dass bestimmte Aufgaben bewusst gemieden werden, weil sie vermutlich länger dauern werden als vorab geschätzt – und damit „unproduktive Tätigkeiten“ sind. Auf der anderen Seite kann eine minutiöse Zeiterfassung im Dev-Umfeld auch dazu beitragen, dass manche Entwickler bestimmte Tasks meiden – getrieben von der Angst, diese nicht in der dafür vorgesehenen Zeit lösen zu können und einen schlechten Eindruck zu hinterlassen. Fakt ist: Niemand kann mit Sicherheit vorhersagen, wie lange es dauern wird, einen (nicht-trivialen) Fehler zu beheben oder eine neue Funktion zu implementieren. Anzunehmen, dass die Softwareentwicklung mit denselben Methoden gemanagt werden kann, wie zu Zeiten der industriellen Revolution, ist grundlegend falsch. Und Entwickler dazu zu zwingen, die Zeit für Aufgaben zu erfassen, die nicht pauschal in Stunden, Minuten und Sekunden gepresst werden können, bringt nur Nachteile. Glücklicherweise erkennen das auch manche Unternehmen. (fm) Sie wollen weitere interessante Beiträge zu diversen Themen aus der IT-Welt lesen? Unsere kostenlosen Newsletter liefern Ihnen alles, was IT-Profis wissen sollten – direkt in Ihre Inbox! 

Entwickler gehören nicht ans Fließband!​ Alles ganz modern? Everett Collection | shutterstock.com Seitdem im Jahr 1946 der Großrechner ENIAC an die US-Armee ausgeliefert wurde, ringen Unternehmen und Organisationen damit, die Softwareentwicklung effektiv zu managen. Das Problem ist aus dem militärischen Bereich bekannt: Bei der Vorbereitung auf künftige Konflikte wird vor allem über die bereits ausgetragenen nachgedacht. Das kann dazu führen, dass Technologien und Strategien angewendet werden, die in der Vergangenheit zwar effektiv waren – mit Blick auf die Zukunft allerdings nicht dasselbe versprechen. Früher wurden die Mitarbeiter in Fabriken dazu aufgefordert, die Stechuhr zu drücken – und von durch die Flure wandernden Managern kontrolliert. Das machte auch Sinn, wenn es beispielsweise darum ging, Verschlusskappen auf Rasierschaumdosen zu setzen. Die Leistung der Arbeiter war einfach zu erfassen, ihre Anzahl ein guter Erfolgsindikator: Je mehr Füße am Fließband standen, desto mehr wurde produziert. Leider wurde dieses Konzept auch für die Softwareentwicklung übernommen. Nur, dass Füße und Fließband dabei durch „Hintern“ und „Stühle“ ersetzt wurden. Mehr Hintern, mehr Software? Das ist umso erstaunlicher, weil die meisten nicht-technischen Führungskräfte gar nicht beurteilen können, was Developer eigentlich tun – geschweige denn, wie gut und ob das in angemessener Geschwindigkeit abläuft. Das macht es quasi unmöglich, die Produktivität einzelner Softwareentwickler zu messen. Die „Zauberformel“ vieler Manager scheint sich deshalb am Rasierschaumdosen-Beispiel zu orientieren: Je länger diese Menschen auf ihren Tastaturen herumhämmern, desto mehr muss am Ende auch produziert werden – was auch immer das genau sein mag. Mit Blick auf die Praxis zeigt sich, wie realitätsfern diese Sichtweise ist. Etwa, wenn ein Entwickler 1.300 Zeilen Spaghetti-Code eliminiert und sie durch 200 deutlich elegantere und effizientere Code-Zeilen ersetzt. Oder wenn Developer eine Woche damit verbringen, ein Projekt ordentlich aufzusetzen, um damit dem Team unzählige Arbeitsstunden zu sparen. Manager verspüren eben oft nur den Drang, etwas zu messen. Das ist in der Regel die für einen Task aufgewendete Zeit. Deswegen sind nicht wenige Dev-Teams dazu angehalten, die Zeit für jede einzelne Aufgabe wie etwa die Fehlerbehebung zu erfassen. Schlimmer wird es dann nur noch, wenn die erfassten Zeiten auch noch miteinander verglichen werden, um ein Maß für Produktivität und Erfolg zu bestimmen.    Die schlimmste Kennzahl überhaupt Eine minutiöse Zeiterfassung im Softwareentwicklungsumfeld ist aus verschiedenen Gründen kontraproduktiv: Geht es darum, Software zu schreiben, gleicht kein Fehler dem anderen. Unerfahrene Entwickler sind vielleicht in der Lage, schnell Lösungen für viele einfache Fehler zu finden. Erfahrenere Entwickler, die sich im Allgemeinen  anspruchsvolleren Problemen widmen, brauchen entsprechend länger. Und was, wenn einem Junior-Entwickler ein Fehler zugewiesen wird, den er nicht bewältigen kann? Die Zeit für einzelne Tasks erfassen zu müssen, könnte manche Devs dazu ermutigen, das System zu manipulieren. Das führt dann dazu, dass bestimmte Aufgaben bewusst gemieden werden, weil sie vermutlich länger dauern werden als vorab geschätzt – und damit „unproduktive Tätigkeiten“ sind. Auf der anderen Seite kann eine minutiöse Zeiterfassung im Dev-Umfeld auch dazu beitragen, dass manche Entwickler bestimmte Tasks meiden – getrieben von der Angst, diese nicht in der dafür vorgesehenen Zeit lösen zu können und einen schlechten Eindruck zu hinterlassen. Fakt ist: Niemand kann mit Sicherheit vorhersagen, wie lange es dauern wird, einen (nicht-trivialen) Fehler zu beheben oder eine neue Funktion zu implementieren. Anzunehmen, dass die Softwareentwicklung mit denselben Methoden gemanagt werden kann, wie zu Zeiten der industriellen Revolution, ist grundlegend falsch. Und Entwickler dazu zu zwingen, die Zeit für Aufgaben zu erfassen, die nicht pauschal in Stunden, Minuten und Sekunden gepresst werden können, bringt nur Nachteile. Glücklicherweise erkennen das auch manche Unternehmen. (fm) Sie wollen weitere interessante Beiträge zu diversen Themen aus der IT-Welt lesen? Unsere kostenlosen Newsletter liefern Ihnen alles, was IT-Profis wissen sollten – direkt in Ihre Inbox!

Entwickler gehören nicht ans Fließband!​

Alles ganz modern? Everett Collection | shutterstock.com Seitdem im Jahr 1946 der Großrechner ENIAC an die US-Armee ausgeliefert wurde, ringen Unternehmen und Organisationen damit, die Softwareentwicklung effektiv zu managen. Das Problem ist aus dem militärischen Bereich bekannt: Bei der Vorbereitung auf künftige Konflikte wird vor allem über die bereits ausgetragenen nachgedacht. Das kann dazu führen, dass Technologien und Strategien angewendet werden, die in der Vergangenheit zwar effektiv waren – mit Blick auf die Zukunft allerdings nicht dasselbe versprechen. Früher wurden die Mitarbeiter in Fabriken dazu aufgefordert, die Stechuhr zu drücken – und von durch die Flure wandernden Managern kontrolliert. Das machte auch Sinn, wenn es beispielsweise darum ging, Verschlusskappen auf Rasierschaumdosen zu setzen. Die Leistung der Arbeiter war einfach zu erfassen, ihre Anzahl ein guter Erfolgsindikator: Je mehr Füße am Fließband standen, desto mehr wurde produziert. Leider wurde dieses Konzept auch für die Softwareentwicklung übernommen. Nur, dass Füße und Fließband dabei durch „Hintern“ und „Stühle“ ersetzt wurden. Mehr Hintern, mehr Software? Das ist umso erstaunlicher, weil die meisten nicht-technischen Führungskräfte gar nicht beurteilen können, was Developer eigentlich tun – geschweige denn, wie gut und ob das in angemessener Geschwindigkeit abläuft. Das macht es quasi unmöglich, die Produktivität einzelner Softwareentwickler zu messen. Die „Zauberformel“ vieler Manager scheint sich deshalb am Rasierschaumdosen-Beispiel zu orientieren: Je länger diese Menschen auf ihren Tastaturen herumhämmern, desto mehr muss am Ende auch produziert werden – was auch immer das genau sein mag. Mit Blick auf die Praxis zeigt sich, wie realitätsfern diese Sichtweise ist. Etwa, wenn ein Entwickler 1.300 Zeilen Spaghetti-Code eliminiert und sie durch 200 deutlich elegantere und effizientere Code-Zeilen ersetzt. Oder wenn Developer eine Woche damit verbringen, ein Projekt ordentlich aufzusetzen, um damit dem Team unzählige Arbeitsstunden zu sparen. Manager verspüren eben oft nur den Drang, etwas zu messen. Das ist in der Regel die für einen Task aufgewendete Zeit. Deswegen sind nicht wenige Dev-Teams dazu angehalten, die Zeit für jede einzelne Aufgabe wie etwa die Fehlerbehebung zu erfassen. Schlimmer wird es dann nur noch, wenn die erfassten Zeiten auch noch miteinander verglichen werden, um ein Maß für Produktivität und Erfolg zu bestimmen.    Die schlimmste Kennzahl überhaupt Eine minutiöse Zeiterfassung im Softwareentwicklungsumfeld ist aus verschiedenen Gründen kontraproduktiv: Geht es darum, Software zu schreiben, gleicht kein Fehler dem anderen. Unerfahrene Entwickler sind vielleicht in der Lage, schnell Lösungen für viele einfache Fehler zu finden. Erfahrenere Entwickler, die sich im Allgemeinen  anspruchsvolleren Problemen widmen, brauchen entsprechend länger. Und was, wenn einem Junior-Entwickler ein Fehler zugewiesen wird, den er nicht bewältigen kann? Die Zeit für einzelne Tasks erfassen zu müssen, könnte manche Devs dazu ermutigen, das System zu manipulieren. Das führt dann dazu, dass bestimmte Aufgaben bewusst gemieden werden, weil sie vermutlich länger dauern werden als vorab geschätzt – und damit „unproduktive Tätigkeiten“ sind. Auf der anderen Seite kann eine minutiöse Zeiterfassung im Dev-Umfeld auch dazu beitragen, dass manche Entwickler bestimmte Tasks meiden – getrieben von der Angst, diese nicht in der dafür vorgesehenen Zeit lösen zu können und einen schlechten Eindruck zu hinterlassen. Fakt ist: Niemand kann mit Sicherheit vorhersagen, wie lange es dauern wird, einen (nicht-trivialen) Fehler zu beheben oder eine neue Funktion zu implementieren. Anzunehmen, dass die Softwareentwicklung mit denselben Methoden gemanagt werden kann, wie zu Zeiten der industriellen Revolution, ist grundlegend falsch. Und Entwickler dazu zu zwingen, die Zeit für Aufgaben zu erfassen, die nicht pauschal in Stunden, Minuten und Sekunden gepresst werden können, bringt nur Nachteile. Glücklicherweise erkennen das auch manche Unternehmen. (fm) Sie wollen weitere interessante Beiträge zu diversen Themen aus der IT-Welt lesen? Unsere kostenlosen Newsletter liefern Ihnen alles, was IT-Profis wissen sollten – direkt in Ihre Inbox! 

Nach oben scrollen