Die Evolution der Tools in der Softwareentwicklung

Die Evolution der Tools in der Softwareentwicklung

Von Compilern zu Digital Boardrooms

Software Engineering als Disziplin befindet sich noch in einer niedrigeren Evolutionsstufe als die traditionellen, älteren Ingenieurwissenschaften. Im Vergleich zu Softwareentwicklung arbeitet man im Automobilbau zum Beispiel schon seit spätestens den 80er Jahren mit dem von Toyota eingeführten 'Lean Manufacturing'-Ansatz auf höchstem Prozessniveau. Warum? Neben den eigentlichen Werkzeugen und Förderbändern und allem, was man braucht, um ein Auto zusammenzuschrauben und zusammenzuschweißen aus den einzelnen Bauteilen, sollte man auch noch Werkzeuge und Plattformen einsetzen, mit denen man beobachten kann, wie der Gesamtprozess von Anfang bis Ende funktioniert. Damit lässt sich dieser Gesamtprozess auch einfach optimieren – ein Must-Have im Automobilbau. Ohne dies hätten Automobilbauer keine Chance auf dem Markt. Nur leider sind wir in der Softwareentwicklungswelt noch nicht an diesem Punkt angekommen. Oder doch?

Von Hammern und Schraubenziehern - Compiler und Programmierungsumgebungen

Was waren die ersten Softwareentwicklungstools, die eine gewisse Messbarkeit vom Softwareentwicklungsprozess ermöglichten? Die ersten Werkzeuge von Softwareentwicklern waren im Grunde Compiler und Programmierumgebungen, sozusagen Hammer und Schraubenzieher. Prominentes Beispiel aus der Java-Welt für eine Programmierumgebung ist 'Eclipse'. Danach kamen die Version Control Systems, also dort, wo Quellcode systematisch verwaltet wird. Im Grunde die Lagerhaltung, Regalsysteme, in denen in großem Stil die Bauteile sauber geordnet liegen. Ein Beispiel ist 'IBM Clear Case', immer noch sehr häufig im Gebrauch, obwohl es auch aus den 80ern stammt. Ein anderes hieß 'Subversion'. Heutzutage nutzen die meisten 'Git' - alle 'Digital Natives'.

Roboter und Roboterarme - Continuous Integration/Delivery-Systeme

Die nächste Art von Tools und Werkzeugen sind die sogenannten Buildautomatisierungssysteme. Heute bezeichnet man diese als CI/CD-Systeme (Continuous Integration/Continuous Delivery Systeme). Diese nehmen den Quellcode und wandeln ihn automatisch in ausführbare Komponenten um. Diese sind die Roboter, die in die Regallager fahren, die Bauteile rausholen und dann auf Fließbänder legen und die Roboterarme, die das fahrende Auto daraus zusammensetzen. Es ist üblich, dass CI/CD-Systeme außerdem auch die von den Entwicklern zum Programmcode geschriebene Tests ausführen, mit welchen geprüft wird, ob der Quellcode tatsächlich das Gewünschte fehlerfrei leistet. Falls die Tests fehlschlagen, werden digitale Alarmglocken geläutet und die Entwickler müssen nachbessern. Im Sinne der Roboteranalogie bliebe das Fließband also stehen, falls die Produktionsanlage feststellt, dass die Beifahrertür ohne Weiteres aufgeht, wenn der rechte Blinker getätigt wird - 'Ups!'. In der Softwarewelt ist das prominenteste Tool an dieser Stelle 'Jenkins'.

Prüfung von Bauteilen auf Fließbändern - Statische Codeanalyse

Dann kam die Zeit der Werkzeuge zur statischen Codeanalyse und ihrer Integration in CI/CD-Systeme. Mit solchen Systemen, die als automatisierte Prüfgeräte fungieren, wird der Quellcode, wenn er in ausführbare Systemkomponenten umgewandelt wird, auf bekannte Sicherheitslücken, potentielle Fehler, einheitlichen Programmierstil, Wartbarkeit, Performanz usw. untersucht. Analog zur Automobil-Fabrik werden alle Bauteile, die zusammengebaut werden, Einzelteilte oder funktionsfähige Komponenten, die auf Fließbändern vorbeifahren, geprüft und fehlerhafte Bauteile identifiziert. Ein bekanntes Bespiel für diese Art von Tools ist 'Sonarqube'.

Bauteile erweitern per Arbeitsauftrag - Issuetracking-Systeme

Als letzte Kategorie, die dazugekommen ist, gibt es die sogenannten Issuetracking-Systeme, in denen die Stapel der Arbeitsaufträge liegen. Dort gibt es Werkzeuge, die eine verbesserte Koordinierung der Arbeitsaufträge ermöglichen. Softwareentwickler nehmen sich so einen Auftrag, gehen ins Bauteillager und holen sich die zu erweiternden Bauteile auf den Schreibtisch. Sprich, sie holen sich den Code aus Git. Dann erweitern die das Bauteil entsprechend der Anforderungen im Arbeitsauftrag. Dann tragen sie das veränderte Bauteil wieder zurück ins Regal. Danach wird der veränderte Code wieder ins Git eingecheckt. Ein Tool für dieses Issuetracking, das sich mittlerweile als Platzhirsch etabliert hat, ist 'Jira'. 

Die neue Stufe der Evolution – Hoffnungsschimmer für die Optimierung von Software-Fabriken

Jeder Beteiligte im Softwareentwicklungsprozess ist gut ausgerüstet mit Werkzeugen, die er/sie braucht und in den Händen halten muss, um damit die eigene Arbeit gut zu erledigen. Die Namen, die hier genannt worden, sind rein exemplarisch. Es gibt in diesem Ökosystem mehrere Hundert Tools – Hammer, Schraubenzieher, Spezialzangen und so weiter.  

Was sich aber im Softwareentwicklungsbereich noch nicht herausgebildet hat, ist eine Möglichkeit den Prozess im Ganzen zu sehen – von Anfang bis Ende. Wenn man diese Transparenz hat, kann man anfangen Optimierungsaufgaben durchzuführen, die die Entwicklungsorganisation immer mehr verbessert. Allerdings gab es bisher keinen Begriff für diese Kategorie. Als Verantwortlicher für eine große Softwareentwicklungsorganisation, wenn ich alles im Blick haben will, wüsste ich noch nicht einmal, welche Suchbegriffe ich in Google eingeben muss, um Hilfe zu finden.  

Es gibt aber einen Hoffnungsschimmer. Aus dem universitären Umfeld etablieren sich methodische Ansätze, bzw. erste Plattformen, die man im großen Stil auf echte große, industrielle Softwareentwicklungsorganisationen anwenden kann. Diese Plattformen analysieren, welche Datenspuren die oben genannten Tools hinterlassen. Wenn man z.B. ein CI/CD-System durchlaufen lässt, entstehen Datenspuren. Quasi unten im Kellergeschoss liegt dann eine Menge an #Datengold. Diese neuen Plattformen nutzen dieses Datengold aus, um dann aus den Datenspuren den real gelebten Entwicklungsprozess zu rekonstruieren, und zwar mit all seinen Schnörkeln und Ineffizienzen. 

Dies gibt vollkommene Transparenz darüber, wie gut die Fabrik wirklich läuft, was wirklich in der Werkshalle passiert. Das ist nicht irgendwas, was ein Mensch mal in einem Report angibt und sagt, 'Ja, die Situation ist ganz okay.', sondern die Datenspuren sind auch Ground Truth, also die Wahrheit. Diese Datenspuren werden genutzt, um KPIs (Key Performance Indicators) abzuleiten, mit denen man auf strategisch-operative Ebene Indikatoren hat, die über reine Code-Betrachtung hinausgeht. Alle Dimensionen der Softwareentwicklung können mit objektiven Zahlen hinterlegt werden, so kann ein Verantwortlicher für Softwareentwicklung die Situation quantifiziert erfassen und beobachten. Es wird zu guter Letzt eine Art #DigitalBoardroom geschaffen wo all diese wichtigen KPIs abgelegt werden. Verantwortliche können jeden Tag in Echtzeit sehen, an welchen Stellen es Probleme in ihren Werkshallen gibt, und wo er/sie vielleicht einschreiten sollte in die Entwicklungsorganisation – analog zum Werksvorsteher. 

Allerdings ist dies nicht mehr die Kultur in der Softwareentwicklung, sondern wird getragen von kollaborativer Arbeit. Das Team in Gänze arbeitet und entscheidet, gerade in der agilen Welt. Aber nichtsdestotrotz braucht man Transparenz. Damit jeder Beteiligte der Software-Fabrik objektive Zahlen auf dem digitalen Boardroom sehen kann 'Da stehen wir. Wenn wir jetzt die Releaseprojekte mit so viel Zeitdruck da durchpeitschen, häufen wir die ganze Zeit technische Schuld an. Sprich, das sollte man mal einplanen im nächsten Releasezyklus - so einen technischen Schuldabbau.' Solche Art von Entscheidungen kann man bewusst treffen, wenn man sieht, wie sich die KPIs verändern.  

Nur so kann man Softwareentwicklung gut in den Griff bekommen. Es kristallisiert sich nun auch ein Begriff für diese Art von Plattformen heraus: Digital Boardrooms. Sie vereinen Techniken der #SoftwareAnalytics oder #SoftwareProcessMining. Als bisher höchste Stufe der Evolution können Digital Boardrooms die Software-Fabrik zum kompletten Erfolg verhelfen. Bald nun wird sich die Überzeugung durchgesetzt haben, dass es nicht ausreicht, die Entwickler oder die Beteiligten mit Hammern, Schraubenziehern, Förderbändern oder Roboterarmen auszurüsten. Dies allein reicht nicht für exzellente Softwareentwicklung, man sollte wie im Maschinenbau agieren, nämlich mit der Hilfe von datenbasierter Prozessoptimierung. Ein Digital Boardroom wird somit ein Must-Have für eine Organisation, die Softwareentwicklung betreibt.

Autoren: Dr. Johannes Bohnet, Dr. Uta Morgenstern

 #DigitalEngineering #MadeinGermany #SoftwareFactory #SoftwareDevelopment #Seerene