de.buildblog.reflect – Meilensteine in der Programmierung

Softwareentwicklung

de.buildblog.reflect – Meilensteine in der Programmierung

de.buildblog.reflect – Meilensteine in der Programmierung

In der Literatur ist oft die Rede von Meilensteinen und wie eminent wichtig sie im Rahmen der Softwareentwicklung sind. Das stimmt wohl, allerdings muss man auch das große Ganze im Auge behalten. Viel zu oft wird das leider sträflich vernachlässigt. Da steht der Architekt am Besprechungstag vor seiner Mannschaft und ist völlig enttäuscht, weil nichts fertig ist. “O.k., dann seht mal zu Jungs, dass ihr das hinkriegt und dann machen wir mit der nächsten Etappe weiter …”  Schon gemerkt? Genau – hier trennt sich die Literatur von der Praxis. Während also die reine Lehre weiter träumt, werden im echten Leben die Daumenschrauben ausgepackt. Ob zu Recht oder zu Unrecht sei nun erstmal dahingestellt.

Jedenfalls wird im Großteil der Fälle der geplante, folgende Meilenstein nicht verschoben. Zum Leidwesen derer die diesen letzten bereits nur durch Überstunden verpassten. Ohne Gnade (und Verstand) wird an dem vorgegebenen Zeitplan festgehalten und dabei kommt dann folgerichtig Murks zustande. Bitter ist es wenn das eine Weile so weiter läuft. Murks auf dem noch mehr Murks aufsetzt ist eben größerer Murks aber bei weitem nicht besser als der Anfang.

Diskussion

Ein Kommentar zu “de.buildblog.reflect – Meilensteine in der Programmierung”

  1. [...] 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? [...]

    Posted by buildblog | de.buildblog.reflect - Meilensteine II - Murks und seine Freunde | Februar 20, 2009, 17:02

Post a comment