Entwickler unter Zeitdruck: „Hätte ich mehr Zeit gehabt, dann hätte ich weniger Code geschrieben“

Hartmut Schlosser

(c)  Shutterstock /  mypokcik

Hätte ich mehr Zeit gehabt, dann hätte ich weniger Code geschrieben – mit diesem Zitat regt Blogger David Green auf Actively Lazy zu einigen spannenden Gedankengängen an. Seine Anfangsthese lautet: Je mehr Zeit man für die Lösung eines Programmierproblems zur Verfügung hat, desto kürzer, eleganter und deshalb oft auch besser fällt der Quellcode aus. Doch halt! Gibt es da nicht die genau gegenteilige Programmierweisheit aus dem Kreise der Software-Craftmanship-Initiative: „The only way to go fast is to go well“ (Uncle Bob)?

Zeitdruck – das alte Lied

Zunächst einmal die Frage, warum Entwickler eigentlich permanent unter Zeitdruck sind. Die meisten von Ihnen kennen das sicherlich:

  • Die „heilige“ Deadline – Werbung für das Projekt ist bereits eingekauft, oder es gibt ein externes Ereignis, zu dem das Projekt fertig sein muss.
  • Die Kosten für das Projekt müssen noch in diesem Geschäftsquartal abgerechnet werden.
  • Ein Entwickler hat einen Zeitpunkt genannt, zu dem er und sein Team das Projekt „problemlos“ schaffen sollten, und will nun nicht das Gesicht verlieren.

Was dann aus Zeitgründen meist wegfällt, sind Dinge wie das Testen oder das Refactoring – frei nach dem Motto: „Wir fixen das in der nächsten Version.“ Oder man nimmt sich nicht die Zeit, ein Problem erst einmal gründlich zu analysieren und nach der besten Lösung zu suchen. Gleich geht man ans Coden – und probiert so lange herum, bis es einigermaßen tut, was man denkt, dass der Kunde will.

Ist schnell wirklich schneller?

Doch funktioniert dieses Hetzverfahren tatsächlich? Zunächst einmal fühlt es sich oft so an, als komme man zu schnelleren Ergebnissen: Die Ecken wurden rund gemacht, die gewünschten Features zu einem gewissen Prozentsatz funktional in die Software integriert und eine Art „fertige Version“ zur Deadline ausgeliefert.

Die Rechnung hat man aber dann meist im Nachhinein zu bezahlen:

  • Die „Zeitersparnis“, die Anforderungen nicht bis ins Detail auszudiskutieren, führt zu Missverständnissen. Der Kunde wollte es eigentlich anders und fordert Nachbesserungen.
  • Die „Zeitersparnis“, ohne Design-Plan loszuprogrammieren, führt in architektonische Sackgassen (z.B. Performance- und Skalierungsprobleme), aus denen man sich – wenn überhaupt – nur unter großem Zeitaufwand retten kann.
  • Die „Zeitersparnis“, das Refactoring auszulassen, führt zu unsauberem Code, der schwer zu warten ist.

Entwickler – der professionelle Zeitmanager

Man sollte sich also für jede Programmieraufgabe ein wenig Zeit einplanen, um Anforderungen zu besprechen, mit Kollegen über das Design zu diskutieren und den Code zu refaktorisieren. Idealerweise ist die Zeit gerade so lang, dass die Aufgabe so schnell wie möglich gelöst werden kann.

  • Ist diese Zeit zu kurz, werden möglicherweise Zusatzarbeiten im Nachhinein notwendig
  • Ist diese Zeit zu lang, verschenke ich wertvolle Kodierzeit

In dieser Hinsicht scheint die professionelle Software-Entwicklung immer ein Balance-Akt zu sein zwischen der Zeit, die ich für Programmierung zur Verfügung habe, und der Zeit, die ich für andere Dinge wie Design, Refactorings, Meetings, ect. aufwenden sollte. Um die Zeit richtig einschätzen zu können, ist Erfahrung nötig.

Vielleicht kennen Sie auch diesen typischen Prozess der Reifung als Entwickler, den David Green an sich selbst diagnostiziert:

  • Als Anfänger stürzt man sich in die Programmierung, ohne sich vorher große Gedanken über ein Problem zu machen. Man muss deshalb den Code wieder und wieder umschreiben und verliert am Ende dadurch viel Zeit.
  • Hat man dies erkannt, geht man zum Gegenteil über: Man diskutiert im Vorhinein jede Anforderung aus, schreibt Design-Pläne, spezifiziert und refaktort so lange, bis der Code perfekt ist (bzw. scheint). Aber man merkt auch hier, dass vieles am Aufwand, den man vor der eigentlichen Programmiertätigkeit betrieben hat, letztlich unnötig war.
  • Als erfahrener Entwickler findet man schließlich eine bessere Balance zwischen vorbereitenden Arbeiten und dem eigentlichen Programmieren.

Zeitdruck – die faule Ausrede?

Wie genau die ideale Zeiteinteilung beim Lösen eines Programmierproblems ist, kann man freilich nicht genau messen – auch wenn David Green einige schöne Grafiken bereit hält.

Interessant ist aber der Gedanke, ob der Zeitdruck nicht allzu oft auch als Entschuldigung herangezogen wird, um nicht nochmal mit dem Kunden sprechen zu müssen, um nicht die eigene Idee von den Kollegen verrissen zu bekommen, um nicht das lästige Design-Problem diskutieren zu müssen.

Denn meist sind es nur wenige Minuten Vorabaufwand, die einem letztlich Stunden an nachträglichem Fixen sparen:

  • Warum nicht jedes Feature nochmal 10 Minuten lang mit dem Kunden diskutieren?
  • Warum nicht 20 Minuten mit den Kollegen ans Whiteboard gehen und die Architektur besprechen?
  • Warum nicht 30 Minuten Refaktorisieren und Dokumentieren, um nicht in den nächsten Wochen und Monaten Tage mit unverständlichem Spagetti-Code zu verlieren?

Und um es an dieser Stelle einmal etwas provokant zu formulieren: Statt täglich diese eine Stunde einzuplanen, verbringen die meisten Entwickler doch lieber den Nachmittag unproduktiv damit, nach einer Technologie oder nach Code-Snippets zu surfen, die ein Problem lösen, das der Kunde so gar nicht hat, oder?

Aufmacherbild: Stress Management in word collage von Shutterstock / Aufmacherbild: mypokcik

Verwandte Themen:

Geschrieben von
Hartmut Schlosser
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: