Entwickler: Die unverstandenen Künstler

Gib es zu: Du bist ein schlechter Programmierer! Mit diesem polemischen Titel rüttelte Jared Richardson all diejenigen Entwickler wach, die sich in maßloser Selbstüberschätzung für die Speerspitze des Fortschritts halten und die Schuld für das Scheitern eines Projektes stets außerhalb des eigenen Verantwortungsbereichs suchen.

Du bist schuld!

Richardson erläutert in den Kommentaren seinen Standpunkt etwas genauer: Kritisieren wollte er hauptsächlich eine Tendenz unter Entwicklern, äußere Faktoren – allen voran das Management – für das eigene Scheitern verantwortlich zu machen. Dabei gehört es laut Richardson auch zur Aufgabe eines Entwicklers, mit den Managern derart in Dialog zu treten, dass diese der Notwendigkeit des Einsatzes gewisser Werkzeuge, der Einführung agiler Prozesse, der Anpassung unrealistischer Release-Zeitpläne guten Gewissens zustimmen. Denn gute Manager sehen durchaus ein, dass sie von der Materie weniger verstehen als der Entwickler!

Our managers, at least the good ones, know they don’t understand what we do. Provide them reasonable options and they’ll often take it. If we think that failed projects are ~never~ developer’s faults, then we’ve spotted the problem… let’s swing the pendulum back to the middle. Jared Richardson

Viele Wege gibt es dabei, wie Entwickler ihre Manager „managen“ können: In kurzen Iterationen funktionierende Features bereitzustellen, ist einer davon: Gib den Chefs ´was zu sehen, und verstehe lieber früher als später, ob das Projekt in die von oben gewünschte Richtung geht!

Andere agile Methoden wie Kanban, Swim Lane Charts oder The List könnten ebenso helfen: Frag´ deine Chefs, welche fünf Features als nächstes umgesetzt werden sollen! Das gleiche gilt im Umgang mit den Kunden – diese ständig in den Entwicklungsprozess mit einzubeziehen, hilft dabei, Probleme frühzeitig zu erkennen.

Manager versus Entwickler?

Was Richardson also im Grunde anspricht, ist ein Kommunkationsproblem zwischen Auftraggeber und ausführendem Entwickler – ein Problem, das seinen Ursprung laut Richardson auch in einem weit verbreiteten Berufsethos unter Entwicklern hat, die das eigene Projekt gerne als Kunstwerk begreifen möchten, das sie ihren Auftraggebern stolz in Vollendung vor die Füße werfen. Die zwangsläufig fällige Kritik wird dann oft als fachfremde Einmischung missverstanden: Muss es sich der unverstandene Künstler doch zumuten, sein Werk den kleinkarierten Anforderungen des Managements anzupassen!

Developers in general have gotten entirely too comfortable throwing the blame at managers and customers when projects fail. Jared Richardson

Und so lautet Richardsons Schlussappell:

Grow up and accept your share of the blame. Jared Richardson

Wer hat recht?

Weniger Vertrauen in die Einsichtsfähigkeit von Managern hat indes Kommentator And Bod:
Ja, Programmierer hätten in der Tat ein Talent dafür, herauszufinden, warum ein Projekt nicht ihretwegen gescheitert ist. Grund für diese Gabe sei allerdings, dass es meistens wirklich andere verbockt hätten:

Yes sir, it’s true, programmers are great at finding out reasons why it wasn t their fault, they go to great lengths depicting who did stupid and why. Do you know why they re so skilled at this? […] BECAUSE IT S TRUE. And Bod

Stellt sich nun die Frage, ob dieser Kommentar Ausdruck der Haltung ist, die Richardson kritisiert, oder der Wahrheit doch am nähesten kommt?

Aufmacherbild: funny cartoon genius in various poses von Shutterstock / Urheberrecht: artenot