Wenn Softwareprojekte nicht optimal laufen, werden meist die Entwickler in die Verantwortung genommen. Die Probleme beginnen meist aber schon weit davor …

Auf entwickler.de findet sich der Artikel Softwareentwickler und Perfektionismus, der mir – ehrlich gesagt – etwas sauer aufgestoßen ist.

Der verlinkte Artikel erhebt den Perfektionismus zum Grundproblem von Softwareentwicklern – sehr verallgemeinernd wie ich finde. Kritisiert wird, dass viele Entwickler nach der perfekten Lösung eines Problems suchen bzw. diese dann auch perfekt abbilden möchten. Das mag schon sein, das Rahmenwerk legt in den meisten Fällen aber nicht der Entwickler fest. Hier scheitert es vielfach schon an den mangelhaften Vorarbeiten.

Die Spezifikations-Falle

Die meisten Probleme in der Softwareentwicklung liegen an der vagen Spezifikation der Anforderungen. Würde an dieser Stelle bessere Arbeit geleistet werden, könnte vieles bereits im Vorfeld abgefangen werden. Aber das ist natürlich Aufwand, der oft nicht betrieben werden möchte, denn die Entwicklung wird das schon richten.

Oftmals verdienen Spezifikationen nicht einmal diesen Namen. Anyway. Was passiert wenn jemand etwas einfordert, er aber selbst nicht genau weiß, was es sein soll? Er bekommt entweder nichts (weil die Umsetzung verweigert wird) oder er bekommt irgendetwas, nicht aber, was er wollte.

Viele Projektleiter, Product Owner, Projektmanager etc. tun sich schwer damit, große/komplexe Anforderungen zu zerlegen und sie so aufbauend zu gestalten, dass eine Umsetzung Schritt für Schritt möglich ist. Daraus folgt unweigerlich ein Klärungsmeeting (siehe weiter unten).

Anforderungen können sich ändern und darauf reagieren zu können ist eine gute Sache. Dafür gibt es auch Methoden um dies zu unterstützen bzw. zu kanalisieren (siehe Scrum). Schwierig wird es jedoch, wenn der Auftraggeber/Stakeholder keinen blassen Schimmer hat, was er da will, oder wohin die Reise gehen soll (fehlende Produktvision usw.) und jeden Gedanken in die Entwicklung weiterreicht.

Nicht jeder kann sich vorstellen, wie Software funktionieren kann/soll. Ablaufdiagramme etc. helfen nicht weiter. Nur wenn es implementiert wird, kann man sich das vorstellen und daran Änderungen vornehmen (ein Mockup entspricht da keinem realen Abbild und wird mitunter nicht akzeptiert). Natürlich kann man das machen, ist aber a) eine sehr teure Angelegenheit und b) bringen die laufenden Veränderungen gerne eine hohe Komplexität ins Spiel (vor allem, wenn Migrationsfähigkeit etc. gewahrt bleiben müssen – dieses Verständnis fehlt jedoch gerne, es muss halt funktionieren, eh klar).

Die Diskussions-Falle

Da findet sich ein ganz interessanter Absatz im ursprünglichen Meeting:

Oftmals wird in Meetings die perfekte Lösung diskutiert. Zwischenlösungen gelten vermehrt als indiskutabel. Man versucht in einer Art kollektivem Gedankenexperiment den gesamten Verlauf eines Zwei-Jahres-Projekts millimetergenau zusammen zu zimmern.

Ich kenne diese Diskussionen. Hierbei dreht es sich aber selten um die perfekte Lösung, vielmehr geht es darum, eine Lösung zu vermeiden, die wie ein Bumerang zurückkommt. Bei den angesprochenen „Zwischenlösungen“ geht es meist um Problemlösungen. Während Manager natürlich den schnellen Fix (der kann doch schon mal schmutzig sein) bevorzugen, möchte der Softwareentwickler, dass das Problem nicht über Umwegen wieder zurückkommt, sondern nachhaltig gelöst wird. Natürlich kann man das als Perfektionismus abtun, in Wahrheit sind es Kosten, die man vor sich herschiebt und immer höher werden.

Ganz besonders interessant finde ich den Hinweis auf das „Zusammenzimmern des Verlaufs eines Zwei-Jahres-Projektes“. Niemand kann das, auch ein Softwareentwickler. Vermutlich ist dieser einer der wenigen im Raum, der sich dessen bewusst ist. Auf manche Umstände muss jedoch hingewiesen werden. Nennen wir sie fehlende Vision, fehlender Gesamtüberblick, kein definiertes Ziel, ungenaue Spezifikationen, zu viel offener Spielraum.

Genau diese Dinge führen zu Diskussionen, zahlreichen Fragen, die manchen dann gerne zu viel werden, oder einfach nerven, weil man keine Antwort darauf hat. Im Endeffekt hat man keine Informationen, muss aber dennoch ein System zum Laufen bekommen. Dass das nicht die einfachste Aufgabe ist, kann man sich dann schon mal vorstellen.

Natürlich kann man sich hier auf den Perfektionismus von Softwareentwicklern hinausreden, das Problem liegt aber wo anders.

Zurück zu vagen Anforderungen in großer, angeblich irgendwie zusammenhängender Menge: Die Klärung derselben bedarf natürlich eines Meetings. Der Rahmen ist meist zu groß gewählt, mitunter können auch wenig neue Informationen beigesteuert werden. Genau das führt zu Annahmen auf deren Basis eigentlich keine fundierten Gespräche stattfinden können. Die Aufforderung zur Beschaffung der notwendigen Antworten resultiert gerne in einem „dafür haben wir jetzt keine Zeit“. Das Ergebnis sind Überlegungen, wie man diese Unsicherheiten möglichst in den Griff bekommt. Unnötig anzumerken, dass dies kein Problem der Softwareentwicklung sein sollte.

Die Ego-Falle

Schlussendlich gibt es natürlich auch noch die Ego-Falle. Vor dieser ist auch ein Softwareentwickler nicht gefeit. Gerade junge Entwickler sehen sich gerne in ihrer Ehre angegriffen, wenn etwas nicht optimal läuft, oder werten das Ergebnis ihrer Arbeit als Beschreibung ihrer Persönlichkeit. Natürlich ist das Mist, aber das muss man eben auch erst einmal lernen.

Dass man eine Architektur erst einmal kleinstmöglich ansetzt und mit dem Projekt mitwachsen lässt ist auch ein Produkt langer Erfahrung. Aus diesem Grund bedarf es jedenfalls eines erfahrenen und aufgeschlossenen (!!) Entwicklers, der Euphorie auch einmal bremsen kann, ohne sie gänzlich zu töten. Nennen wir es lenken.

Im Endeffekt ist auch dies ein „Problem“ des Managements. Dieses muss das Team korrekt zusammensetzen und formen, eine langwierige Entwicklungsarbeit, die nur wenige auf sich nehmen. Wenn sich das Management aber lieber damit beschäftigt, wie das Team für eigene Zwecke ideal gesteuert werden kann, der darf sich nicht wundern, dass das Ergebnis nicht den Erwartungen entspricht.

Fazit

In der Softwareentwicklung ist es immer schwierig, die richtige Mischung zu finden. Problematisch ist es immer dann, wenn jemand extrem pragmatisch an die Sache ran geht, oder sehr zu komplexen Lösungen neigt. Im ersten Fall wird die eigentliche Problemstellung oft nicht behandelt, sondern lediglich Symptombekämpfung betrieben (im Falle einer Problemlösung), der zweite Fall führt zur besagten Glaskuppel, die oft erst Jahre später zum eigentlichen Problem wird. Viele Probleme lassen sich tatsächlich im Vorfeld durch die Abklärung der entsprechenden Rahmenbedingungen und der Festlegung eines klaren Zieles vermeiden.

Aus diesem Grund eignen sich agile Ansätze ganz gut, dieser Thematik Herr zu werden, denn durch kurze Iterationen werden kleinere Brötchen gebacken und derartige Auswüchse können in der Regel leichter unterbunden werden.

Über den Autor

Norbert Eder

Ich bin ein leidenschaftlicher Softwareentwickler und Fotograf. Mein Wissen und meine Gedanken teile ich nicht nur hier im Blog, sondern auch in Fachartikeln und Büchern.

2 Kommentare

  • In meinen 8 Jahren habe ich das zu genüge erlebt. Hier schreibt einer der aus der Praxis und nicht aus der Theorie kommt. Ich hatte noch nie Anforderungen die keine Fragen offen liesen. Und oft heisst es: „mach mal.“
    Ergebnis hast du erwähnt. Aus dem mach mal wird dann fast immer ein 2’tes oder 3’tes mal.
    Und ich als Entwickler bin nicht sonderlich darauf erpicht den Kunden/PL nachzurennen.

  • „Gerade junge Entwickler sehen sich gerne in ihrer Ehre angegriffen, wenn etwas nicht optimal läuft, oder werten das Ergebnis ihrer Arbeit als Beschreibung ihrer Persönlichkeit. “

    Schuldig im Sinne der Anklage (naja, ausser jung). Ich habe jetzt einige Zeit mit anderen Aktivitäten experimentiert, und keine ist so Identitätsstiftend für mich.

    Was den Perfektionismus betrifft, habe ich auch schon das Gegenteil erlebt. Ich war in einem sehr kleinen Unternehmen beschäftig, das eine eigene Software modernisieren wollte, von VB auf .Net, aber ein, nichttechnischer, Mitarbeiter klammerte sich daran, die Spezifikation genau definieren zu wollen, und kam ein gutes Jahr nicht damit herum. Ich konnte ein gutes Jahr gar nicht an dem Projekt arbeiten, für das ich eingestellt wurde.

    Was ich statt dessen machte war mit das beste Stückchen Software meiner Karriere, ein Framework, mit dem man, wenn die Spezifikationen endlich kamen, in kürzester Zeit die eigentliche Anwendung generieren hätte können.

    Natürlich wurde das von der GL so gedeutet, dass ICH mich im Perfektionsimus verfangen habe, vor dem Werk scheute man wegen einer Domain Specific Language (XML Struktur) für die Definition zurück und dieses Meisterwerk kam nie zum Einsatz (es war für ein Framework für Desktop Server/Client dass ich so später nicht mehr als Architekturanforderung hatte und damit auch nicht anderweitig nutzen konnte).