Softwareentwicklung: Ein teurer Spass!

Coden ist cool, macht Spass und ist viel weniger aufwendig als früher. Ganz anders dagegen die Software-Entwicklung! Qualität und Effizienz setzen Disziplin voraus und die Compliance ruft die lästigen IT-Architekten auf den Plan. Die Methoden zur Schaffung von Qualität in der Software-Entwicklung sind zwar je nach Unternehmen extrem verschieden, gehören aber allesamt in den Bereich des Uncoolen: komplexe Prozesse bei den einen, aus­geprägte Teamarbeit bei den anderen und Anti-Pattern-Verbot bei den ganz konsequenten Arbeitgebern. Ich bezweifle auch, dass die recht zahlreichen Methoden zur Qualitätssicherung in agilen Projekten bei vielen Codern populär sind. Allerdings gibt es kaum Forschung dazu. 

Leiter von Software-Projekten haben in jedem Fall die schwierige Aufgabe, die Rahmenbedingungen dafür zu schaffen, dass es beides gibt: Spass und Ordnung. Erfolg braucht individuelle Motivation, eine funktionierende Kommunikation und Zusammenarbeit. Letzteres geht ohne Vertrauenswürdigkeit nicht – und die verlangt Disziplin, etwa beim Einhalten von Terminen. 

Ein Kollege hat einen Aspekt des grundsätzlichen Dilemmas vor 20 Jahren wie folgt formuliert: «Java ist lustiger, J2EE ist produktiver». Daran hat sich nichts geändert, obwohl Spring eventuell der Java EE das Wasser abgraben wird. Immerhin haben die Spassbremsen für alle Pro­grammierenden irgendwann etwas Gutes: Wenn die Coder und Coderinnen nämlich älter werden, können sie noch lange mit den Jungen mithalten, die zwar schneller denken, dafür aber weniger Erfahrung mit den Laufzeitumgebungen und Frameworks haben. Der lockere Spruch meines Kollegen, der seit vielen Jahren ein erfolgreicher Unternehmer ist, weist auf das dunkle Problem der Branche hin: der Hang zum Do-it-yourself Prinzip. Er kommt aus der Freude am Coden, ist aber trotzdem Ausdruck mangelnder Engineering-Kompetenz. Das Do-it-yourself-Prinzip bedeutet nämlich, dass in die Entwicklung der Dienste-Infrastruktur nicht investiert oder diese Infrastruktur nicht genutzt wird. Vieles, was als zentraler Dienst bereitgestellt werden sollte, wird in jeder Applikation neu ent­wickelt. Das vordergründige Ergebnis ist ein doppelter ökonomischer Schaden: Statt Dienste einmal wirklich gut zu bauen, baut man sie oft und schlecht. 

Tatsächlich sind die Folgen aber negativer und schwerwiegender. Ohne funktionierende, zentrale Dienste kann vieles nicht automatisiert werden. Beispielsweise kann das zur Verfügung stellen und anschliessende wieder Frei­geben der benötigten Ressourcen aus der Cloud für eine gewünschte Systemlandschaft nicht per Knopfdruck erledigt werden. Die resultierenden Verzögerungen haben oft hässliche Folgewirkungen, wenn man sich die Mühe des Wartens nicht macht – beispielsweise, wenn man nicht in realistischen Umgebungen testet. Für die Software-Entwicklung gilt das Gleiche wie für die normale Büroarbeit: Eine schlechte UX (User Experience) richtet Schaden an! 

Die gefährlichste Konsequenz einer schlecht ausgebauten IT-Infrastruktur ist aber, dass Reaktionen immer dann besonders lang dauern, wenn es schnell gehen muss, beispielsweise bei Systemabstürzen. Wer Resilienz und Systemagilität anstrebt, wird mit einem Laissez-faire für das Do-it-yourself-Prinzip beim Coden scheitern. Das mag temporär kein Problem sein, weil die Microservices uns vorerst geholfen haben, die Komplexitätsprobleme einzudämmen. Aber mittelfristig wird sich die Vernachlässigung der IT-Infrastruktur als sehr teuer erweisen.