Softwareentwicklung

de.buildblog.reflect – Meilensteine II – Murks und seine Freunde

Die Rede war von Murks, der zu großem Murks wird (wenn es schlecht läuft). Das muss nicht zwangsläufig sein – so gesehen besteht fast immer die Option den Kreis zu durchbrechen und vernünftig zu programmieren. Dazu braucht es Mut und Verständnis. Ein Programmierer weiß ob er guten Quellcode schreibt oder einen Schnellschuß, damit es weitergeht. Wenn er mutig ist, sagt er seinem Architekten was Sache ist. Ein verständiger Architekt erkennt das Dilemma eventuell selbst schon früh in der Entwicklung. Ist das nicht der Fall kann er auch Glück haben und er hat einen mutigen Programmierer, der ihn darauf hinweist. Dann kommt es auf den Architekten an. Springt er über seinen Schatten und gesteht sich ein, dass der Zeitplan und/oder die Herangehensweise schlecht war? Vertritt er das sogar gegenüber seinem Abteilungsleiter und kritisiert eventuell auch dessen Konzept?

Gemäß der reinen Lehre ja, natürlich – schließlich ist auch gerade dieses Feedback der Programmierer besonders gehaltvoll. In der Praxis ist das oft anders. Schließlich geht es auch um Fehler die gemacht wurden. Niemand hört und / oder sieht gerne, dass er was falsch gemacht hat. Das ist einfach so. Viele Bugs und Fehler sind die Folge verletzter Eitelkeiten – oder dem Totschweigen der Fehler bis sie irgendwann für alle sichtbar zu Tage treten. Warum wird sowas offensichtliches totgeschwiegen? Diese Frage wird im nachhinein ganz gerne gestellt. Interessanterweise ist die Antwort zumeist ein Achselzucken. Gerade wenn klar sein muß, dass es eigentlich nur und ausschließlich um verletzte Eitelkeit ging beziehungsweise eben das Nichtverletzen, ist das Achselzucken eine beliebte Antwort.  Erst Recht, wenn nicht Eitelkeit sondern Sturheit und Uneinsichtigkeit eines Vorgesetzten der Grund für schlechten Quellcode ist.

Hoffentlich werde ich niemals folgende Situation vergessen: In einer Besprechung äußerte sich einer meiner Kollegen wie folgt: “Ihr wollt, dass ich Euch Scheiße programmiere? Dann programmiere ich Euch eben Scheiße! Aber wenn wir das so und so machen …” Wenige Wochen später hat er seine Sachen gepackt. “So und so” wurde nie umgesetzt aber der Architekt ist geblieben …

© 2009 buildblog.