Manchmal scheint alles zusammenzubrechen. Im einen Moment arbeitet man noch nach Plan, im Nächsten schlägt urplötzlich der Blitz ein. Die Kunden haben eigenmächtig eine Störung zur GF eskaliert, die Hütte brennt, Panik macht sich breit. Im Bestreben schnell wieder in den regulären Betrieb überzugehen rennt das Team herum wie kopflose Hühner. Planung, Teamarbeit, Qualitätskontrolle? “Doch nicht jetzt” sagt jemand im Vorbeirauschen.
Doch. Genau jetzt. Die Seiteneffekte gerade von Flüchtigkeitsfehlern in der Softwareentwicklung sind nicht nur schwer zu überblicken sondern auch als Ursache schwer festzustellen. In einem konkreten Fall sollte sich herausstellen, dass ein im “Firefighting”-Modus durch einen Einzelnen verursachten Flüchtigkeitsfehler ein gesamter Tag für Fehlersuche draufgehen sollte – weil keine Zeit war noch mal zu prüfen. Produktivitätsverluste im 5-stelligen Bereich sind die Folge. Und wären vermeidbar gewesen.
Selbst wenn es sich gefühlt um kleine Probleme handelt oder der Druck noch so gross, wenn einem der heisse Atem des Geschäftsführers selbst in den Nacken schlägt – niemals ist etwas gewonnen, wenn Probleme mit der heissen Nadel repariert werden. Auch das Argument man könnte es später ja ordentlich machen ist keines – erstens sind damit die Fehler bereits im System und verursachen weitere Panik. Zum Anderen wird meiner Erfahrung nach nie die direkte Behebung dieser sogenannten technischer Schulden eingeplant. Noch Jahre später ist der hastig zusammengeworfene Code im System und verursacht potenziell unaufgedeckte Seiteneffekte und Performanceprobleme.
Mehrere solcher Stellen können ein Produkt komplett zugrunde richten, siehe auch Prototypen, wo bereits zu Beginn eines Projektes Qualität auf dem Weg zu vermeintlicher Geschwindigkeit geopfert wird. Merke: von den drei Stellschrauben Qualität, Umfang und Zeit darf ich immer nur an den letzteren Beiden drehen, ansonsten kompromittiere ich nachhaltig mein Projekt.