Außerhalb der Entwickler-Welt gibt es ja immer mal wieder den Einen oder Anderen, der mit „Entwicklersprech“ nichts anfangen kann. Der von Commits und Libraries noch nie gehört hat, der npm-Pakete nicht kennt und dem die Arbeit eines Entwicklers wie eine Mischung aus Magie und Pizzaessen erscheint.

Ich finde es vollkommen in Ordnung, in solchen Fällen den „Unwissenden“ die Arbeit mit Vergleichen näher zu bringen. „Ein Softwarearchitekt macht etwas Ähnliches wie jeder Architekt, er plant etwas, bevor es aufwändig umgesetzt wird. Nur eben eine Software, kein Haus.“

Aber wenn man mit Entwicklern redet, finde ich solche Vergleiche nicht passend. Ich kannte mal einen Manager, der seinem Entwicklungsbereich die Vorteile der Standardisierung näherbringen wollte und dies seinen Mitarbeiterinnen und Mitarbeitern an einem Beispiel aus der Industrie verdeutlichen wollte. Alle, so meinte er, sollten sich auf die Gewindegrößen einigen und so würden Schrauben, Muttern, Bohrer und Dübel immer zusammenpassen.

Bei den Mitarbeitern sorgte dies in erster Linie für Widerspruch: „Die Kundenwünsche lassen sich nicht in ein Dutzend Standardgrößen abbilden“, „Wir wollen nicht 1000x das Gleiche Loch bohren“ und „Muttern sind keine Schnittstellen“ waren die Reaktionen. Und in erster Linie war der Eindruck: Unser Manager hat offensichtlich keine Ahnung, was wir hier arbeiten, sonst müsste er sich nicht eines solchen Beispiels bedienen.

Warum nutze der Manager in diesem Fall kein Beispiel aus der Softwareentwicklung? Er hatte sogar Wissen aus der Softwareentwicklung (C und C++), hätte er erklärt, welchen Nutzen die Standardisierung der Programmiersprache hatte und beispielsweise den Compilerhersteller zu wechseln, dann wäre er von seinen Mitarbeitern meiner Meinung nach viel mehr ernst genommen worden.

Aber irgendwie scheint es sich etabliert zu haben, dass die Arbeit von Entwicklern immer mit der aus anderen Industrien oder Berufen verglichen werden muss. Schon in „Vom Mythos des Mann-Monats“ vergleicht Frederick Brooks die Arbeit eines Entwicklerteams mit einem Ärzteteam. Zugegeben, bei Erscheinen des Buches war die Erfahrung in der Softwareentwicklung auch noch nicht einige Jahrzehnte alt.

Ich persönlich fühle mich als Entwickler von Managern nicht ernst genommen, die ihre Ideen oder Vorstellungen einleiten mit „Nehmen wir mal an, Entwicklung wäre wie…​ Häuser bauen.“

Sicher, man kann daraus lernen, wie andere (Berufe) ihren Job machen, aber — nehmen wir doch mal an, wir würden Software entwickeln. Und darin wollen wir besser werden.