Gedanken zum perfekten Softwareentwickler

Written on December 04, 2008

the playing board for Black Box, a board game.

Image via Wikipedia

Nachdem Norbert als eine Ursache für mangelhaftes Design den Entwickler selbst ausgemacht hat, möchte ich auch hierzu ein paar Worte verlieren ;-)

(Mindestens) Einer ist immer der Dumme

Norberts Argumentation kann ich mich voll und ganz anschließen.

Allerdings sehe ich nicht nur den Entwickler als Verantwortlichen für schlechtes Design oder schlechte Software als Resultat davon.

Nicht zu vernachlässigen bei diesem Problem sind für mich deren Vorgesetzte und zum Teil auch die Kunden selbst.

Der Entwickler

Bevor ich auf die Vorgesetzten und Kunden eingehe, möchte ich zunächst noch einmal auf den Entwickler zurückkommen.

Ein guter Entwickler, der sein Wissen und seine Techniken stets auf den Stand der Technik bringt, hat imho zwei Möglichkeiten:

  • der einfache Weg: Arbeitsplatzwechsel. Punkt.
  • der steinige Weg: er versucht, Kollegen von seinem Standpunkt bezügl. Unit-Tests u.ä. zu überzeugen, um gemeinsam auch bei den Vorgesetzten ein Umdenken anzustoßen.
    Dies kostet vermutlich einiges an Schweiß und wohl auch Freizeit, kann sich aber unterm Strich dennoch lohnen. Eine gute Argumentationshilfe ist das Buch "Der Pragmatische Programmierer".

Der Vorgesetzte

Ein Problem, das ich bei Vorgesetzten sehe, ist, dass sie überhaupt keinen Verstand für den Software-Entwicklungsprozess mitbringen, sondern schlichtweg Verkäufer sind und Software als Handelsware betrachten.

Die Auswahl für den Kunden soll nach "Schema F" erfolgen, d.h. der Kunde benötigt Feature X und das wars.

Wie Feature X aber aussieht, wird erst hinterfragt, wenn der Entwickler mit der Implementierung beginnt und die Fragen stellt (wenn er sie denn stellt und Feature X nicht einfach nach seiner Interpretation implementiert).

Ein weiteres Problem sehe ich bei der Akzeptanz von Unit-Testing bei Vorgesetzten, da sie den praktischen und langfristigen Nutzen (oder neudeutsch ROI) nicht erkennen.

Möglicherweise, da sie noch nie die Chance hatten, die Vorteile live erleben zu dürfen.

Schließlich sehe ich auch bei den Vorgesetzten mangelndes Verständnis für agile Prozesse (bzw. deren Umsetzung im eigenen Unternehmen) wie z.B. Scrum, die Ihnen die Chance bieten, Projekte permanent und ohne viel Overhead zu überwachen und Probleme frühzeitig zu erkennen.

Der Kunde

In meinen Augen trägt der Kunde, der eine Software anschafft, einen Teil der Schuld, wenn das Projekt scheitert. Warum?

Häufig werden Anschaffungen heutzutage nur noch über den Einkauf erledigt, der vorher bei dem, der das Produkt innerhalb des Unternehmens erhalten soll einige Eckdaten abfrägt und dann bei einer beliebigen Anzahl von möglichen Lieferanten eine Anfrage platziert und letztlich dem preislich attraktivsten Anbieter den Auftrag erteilt.

Ich spreche hier ausdrücklich nicht von Software im Speziellen, sondern von Produkten im Allgemeinen, da dies ein Problem in nahezu allen Wirtschaftszweigen ist.

Evtl. Rückfragen des Lieferanten werden nun unter Umständen über "mehrere Ecken" weitergeleitet. Dass hier Informationsverluste auftreten, dürfte klar sein -- ebenso das Ergebnis.

„Man kann nicht nicht kommunizieren!"

Lack of Communcation

Image by the Frankfurt School via Flickr

Bei allen vorgenannten Beteiligten gibt es sicher noch weitere Aspekte, die zum Scheitern eines Software-Projektes führen können, allen gemein ist meiner Meinung nach aber fast immer das gleiche:

Die mangelnde Kommunikation.

Nur wenn die richtigen Gesprächspartner frühzeitig und häufig miteinander kommunizieren, können mögliche Probleme erkannt und die richtigen Anforderungen erfasst werden - dies gilt übrigens nicht nur bei Software-Projekten.