Was sind die häufigsten Lügen eines Softwareentwicklers?

Was sind die häufigsten Lügen eines Softwareentwicklers?

29.04.2016 in Media & More

Über Selbsttäuschung und Management-Fehler in Software-Projekten…

Die meisten Aussagen sind Variationen von:

  • Das ist noch fehlerhaft, aber ich werde es schnell beheben.
  • Ich bin so gut wie fertig.
  • Wenn’s ein Bug ist, kann der nicht in meinem Code sein.
  • Ich kommentiere und dokumentiere meinen Code später.
  • Läuft auf meiner Maschine.
  • Ist nur eine temporäre Lösung, wird so nicht produktiv gehen.
  • Ich denke, das ist ein Browserproblem.
  • Das ist einfach, dafür brauche ich (nur) eine Woche.
  • Das ist ein Anwenderfehler.

Die meisten dieser Aussagen zeugen entweder von mangelnder Erfahrung … oder Selbsttäuschung, sind also nicht wirkliche „Lügen“. Die wahren Lügen werden von Entwicklern niemals verbalisiert, sie bleiben „im Dunkeln verborgen“.

Im Verborgenen bleiben solche Gedanken wie „Ich kann niemandem von meinem aktuellen Programmierproblem erzählen, deshalb sage ich besser nichts, bis ich aus dem Schlamassel raus bin. Niemand wird den Unterschied merken.“ Damit kommt die Kommunikation ins Stolpern oder gar zum Erliegen. Der Programmierer mag dabei nach außen locker wirken… innerlich ist er aber um seinen mangelnden Fortschritt verlegen.

Einige dieser Aussagen sind Management-Lügen und keine Programmierer-Lügen. Prototypen sind Entwürfe oder Rohfassungen eines Programms. Manager aber sind bekannt dafür, einen Entwurf als Produkt zu verkaufen – üblicherweise bedenken sie dabei nicht die mittel- und langfristigen Implikationen Ihres Vorgehens… Dasselbe gilt für schlampigen, lieblosen, ungetesteten Code.

Im Durchschnitt unterschätzen Entwickler die Arbeit um den Faktor 2, weil sie Tests und Qualitätssicherung vergessen. Wenn es kein detailliertes Design gibt, kann der Faktor sogar bei 3 liegen. Gute Manager wissen darum und korrigieren das (sie beobachten erwartete und tatsächliche Codeauslieferung jedes Programmierers und können so bessere Aufwandsschätzungen bereits nach zwei oder drei Tasks vornehmen).

Gute Softwareentwicklung erfordert viel Zeit, um zu studieren und zu analysieren, was der Anwender wünscht und braucht. Die Bedürfnisse sollten mit dem Kunden ausgehandelt werden. Bildschirmdarstellungen und Benutzeraktionen sollten unter verschiedenen Bedingungen analysiert und Spezifikationen formuliert werden, die Entwickler und Anwender gleichermaßen (!) verstehen. Es sollte eine Design entwickelt werden, das die Spezifikationen in Prozeduren und Funktionen mit spezifischen Parametern und gut dokumentierten Aktivitäten konvertiert. Tests sollten für jedes Element im Design vor der Implementierung der Prozedur oder Funktion entwickelt werden. Die Tests sollten dabei immer von einer anderen Person, als der, die progarmmiert, durchgeführt werden (oft wird jeder ein anderes Verständnis davon haben, was die Prozedur tun soll).

Wenn ein Manager einen Programmierer bittet, etwas ohne eine klare, rückverfolgbare Verbindung zu Design und Analyse zu implementieren, gibt es in der Regel nicht genügend Informationen für den Programmierer, die Lösung gleich beim ersten Mal richtig zu treffen. Der Manager erwartet, dass der Programmierer Tests schreibt und den Code testet – ohne genügend Informationen zu haben. Und niemand überprüft die Tests. Aber ohne ausreichende erste Informationen können die Reparaturen ein Mehrfaches länger dauern als den ersten Code – gut informiert – zu schreiben.

Zu diesem Thema ließe sich noch viel schreiben… Mein Lese-Tipp an dieser Stelle gilt einer Website namens „Clean Code Developer – Eine Initiative für mehr Professionalität in der Softwareentwicklung“. Kurz, knapp, auf den Punkt. Lesenswert – für Entwickler… und Manager!

Copyright © 2009-2024 by multimedia and more - - Impressum - Datenschutz