Über unsMediaKontaktImpressum
Andreas Wickner 02. August 2022

Wie ist die Komplexität von Software-Projekten jetzt und in Zukunft zu bewältigen?

Das Arbeitsumfeld der Software-Entwicklung ist im Laufe der Zeit immer komplexer geworden. Die Anzahl an verfügbaren Werkzeugen und Bibliotheken wächst ununterbrochen. In den letzten Jahren werden die Entwicklungsteams insbesondere mit Cloud-Plattformen konfrontiert, welche hunderte von neuen Services zur Verfügung stellen. Die Einführung von DevOps bringt wiederum zusätzliche Werkzeuge und Prozesse ins Spiel, welche erlernt und beherrscht werden müssen. Bisher wird von den Software-Entwickelnden meistens gefordert, dass sie sich in all dies in kürzester Zeit einarbeiten und den gesamten Prozess beherrschen. Erreichen wir hier vielleicht eine Grenze, bei der dies einfach nicht mehr realistisch ist? Falls dies der Fall sein sollte: Wie wollen wir Software-Projekte in Zukunft organisieren?

Meine eigene IT-Karriere begann Anfang der Achtziger Jahre, als ich Software für 8-Bit-Microcomputer unter dem Betriebssystem CP/M entwickelte. Nostalgische Gefühle kommen bei mir bei der Erinnerung an diese Zeit nur wenige auf und wenn, dann eher in Bezug auf die Menschen, mit denen ich damals zusammengearbeitet habe. Eines ist jedoch sicher: Meine Arbeitswelt war damals erheblich einfacher. Nur wenige Werkzeuge standen uns zur Verfügung: Ein einfacher Texteditor, der Compiler und der Linker zum Zusammenfügen von separat übersetzten Codeteilen. Außer der mit dem Compiler mitgelieferten Standardbibliothek gab es keine weiteren Bibliotheken und auch rudimentäre Debugger waren gerade erst am entstehen. Dass es mit dieser Ausrüstung nicht ganz einfach war, kommerzielle Software zu entwickeln, ist sicher klar, aber an dieser Stelle soll von einer anderen Konsequenz die Rede sein, nämlich der, dass wir diese Ausrüstung außerordentlich gut kannten und beherrschten. Wir waren mit allen Kommandozeilenoptionen von Compiler und Linker bestens vertraut, obwohl es davon eine große Anzahl mit sehr subtilen Konsequenzen gab. Wir kannten auch jede einzelne Funktion der Standardbibliothek mit sämtlichen Parametern.

Heute wäre dies kaum noch denkbar. Größere Software-Projekte nutzen häufig mehrere Programmier- und Konfigurationssprachen und jede davon verfügt über ein ganzes Ökosystem an Werkzeugen. Ein großer Teil der Funktionalität wird von Bibliotheken bereitgestellt. Nicht zuletzt läuft die Software dann auf Ablaufumgebungen, die heute zunehmend mehrschichtig sind (z. B. "Linux in einem Docker-Container" geschichtet auf "Docker", geschichtet auf einem Linux auf konkreter Hardware, um nur ein einfaches Beispiel zu nennen). Ebenfalls an Bedeutung gewinnt die Public Cloud als Zielumgebung für die Software-Entwicklung. Vieles wird durch die Cloud tatsächlich einfacher, allerdings hängt hier auch viel von der geschickten Nutzung der Public-Cloud-Services ab, und hier stehen die Entwickelnden dann vor der Aufgabe, die richtigen der typischerweise um die zweihundert angebotenen Services auszuwählen und sich damit vertraut zu machen. Einige dieser Services besitzen eine beachtliche Komplexität und auch die Querbeziehungen zwischen den Services sind zu berücksichtigen. Diese Plattformen sind auch in ständiger Bewegung: Neue Services kommen hinzu, bestehende Services werden überarbeitet und dies hat wieder Auswirkungen auf thematisch verwandte Services. Eine ausführliche, detaillierte und vollständige Dokumentation bleibt dabei oft auf der Strecke, was insbesondere dann ein Problem darstellt, wenn irgendwo etwas schief geht und dann in diesem Netzwerk aus selbstgeschriebener Software, Bibliotheken und Services die Ursache gefunden werden muss.

Darüber hinaus wird von Software-Entwickelnden heute eine Bereitschaft zu DevOps erwartet, was ein weiteres Arsenal an Fähigkeiten, Prozessen und Werkzeugen mit sich bringt. Die Entwicklungsteams sind nun auch für alle Aspekte von Build und Deployment zuständig, definieren Build-Pipelines und erzeugen virtuelle Deployment-Umgebungen per "Infrastructure as Code". Anstatt wie noch vor wenigen Jahren "das Log-File der Anwendung" auf Fehlermeldungen zu untersuchen, werden jetzt die Meldungen eines Netzwerks von Microservices zentral in einer Datenbank verwaltet. Die zeitlich parallel entstehenden Meldungen müssen zeitlich und inhaltlich korreliert werden, um übergreifende Abläufe verstehen zu können und Fehlerursachen aufzuspüren. All dies ist spannend und stiftet erheblichen Nutzen, muss aber erst einmal erlernt und eingeübt werden.

Bei Diskussionen über die steigende Komplexität der Software-Entwicklung wird häufig versucht, das Problem mit einem Satz vom Tisch zu wischen, der häufig lautet: "Die Software-Entwickelnden müssen halt T-shaped sein". Gemeint ist hier, dass ein breites Spektrum an Fähigkeiten vorhanden sein muss, bei denen ein oberflächliches Wissen ausreicht (entsprechend dem Querbalken des Buchstaben "T") und einige wenige Themen, bei denen Software-Entwickelnde tiefes Wissen mitbringen müssen (der vertikale Balken des "T").

Etwas verallgemeinert und auf den Kopf gestellt, wird das "T" also als ein Säulendiagramm betrachtet, bei dem die horizontale Achse das Themenspektrum abbildet und die vertikale Achse die Wissenstiefe. Die Themen mit „Tiefgang“ werden dabei in der Mitte gruppiert. Auf diese Weise entsteht dann tatsächlich ein Bild, welches einem auf dem Kopf stehenden "T" ähnelt.

Dieses Diagramm ist aber nur dann wirklich "T-shaped", wenn für die "Randthemen" tatsächlich nur ein oberflächliches Wissen erforderlich ist. Typischerweise rücken aber gerade solche "Randthemen" sehr schnell ins Zentrum, sobald etwas schief geht. In solchen Situationen wird dann vom "Full-Stack-DevOps-Engineer" doch eine echte Expertise abverlangt, welche in aller Schnelle erreicht werden muss. Der vertikale Balken des "T" muss in diesem Szenario mit der Zeit immer breiter werden.

An dieser Stelle könnte man nun vermuten, dass dies ja gerade eine optimale Situation darstellt, da die Software-Entwickelnden im Laufe der Zeit immer mehr zusätzliches Wissen ansammeln, bis sie gewissermaßen in jedem Thema über Expertise verfügen. Es ist allerdings auch bekannt, dass echtes Expertenwissen sehr viel Übung nicht nur beim Aufbau erfordert, sondern auch beim Erhalt dieses Wissens. Wenn diese Übung nicht stattfindet, verflacht das Wissen wieder und muss bei Bedarf neu aufgebaut werden. Dies entspricht auch dem üblichen Bild, dass man eigentlich nur über echte Expertise für ein Thema, vielleicht auch für zwei bis drei Themen, aber nicht für zwanzig Themen gleichzeitig verfügen kann. Das "T" wird also im Laufe der Zeit flacher und es ist fraglich, ob dies die Anforderungen des Projektbetriebs noch gut abdeckt.

Wenn man vorübergehend ignoriert, dass auf den horizontalen Achsen dieser Graphen diskrete Themen aufgeführt sind, und die Messpunkte für die Wissenstiefe mit einer kontinuierlichen Kurve interpoliert, dann entsteht eine Darstellung, die einer gaußschen Glockenkurve ähnelt. Meine persönliche, laienhafte These besteht nun darin, dass sich diese Kurve für ein beliebiges Individuum im Verlauf einer Karriere zwar verändern kann, dass die Fläche unter dieser Kurve aber im Wesentlichen konstant bleibt. Die Gesamtmenge des verfügbaren Wissens ändert sich kaum. Je nach Spezialisierung oder Generalisierung kann die Kurve flacher oder spitzer verlaufen.

Wenn es jetzt darum geht, ein Projektteam zu besetzen, hat dies gravierende Konsequenzen. Ein Team von Generalisten verfügt bei keinem Thema über echte Expertise, muss sich daher ständig in Details einarbeiten und kann in Krisensituationen nicht spontan reagieren. Die Teammitglieder sind permanent unter Stress, da sie ständig mit dem Gefühl leben müssen, sich nicht gut genug auszukennen. Ein sorgsam zusammengestelltes Team mit individuellen Expertisen kennt diese Probleme nicht, weil das Team zu jedem Thema über ausreichendes Wissen verfügt. Die "Wissenskurven" decken in der Summe fast den gesamten benötigten Bereich ab.

In solchen Teams können auch Urlaubs- und Krankheitssituationen meist gut überbrückt werden. Es wird zwar selten gelingen, alle relevanten Themen mit jeweils mehreren, über die volle Expertise verfügenden, Personen zu besetzen, das Teilwissen der verbleibenden Team-Mitglieder reicht aber vorübergehend aus.

Mein derzeitiger Arbeitgeber ist ein großes Software- und Beratungshaus, welches fast ausschließlich in solchen Teams arbeitet. Ein Team aus genau den richtigen Personen zusammenzustellen ist aber leider alles andere als einfach. Die Stärken der Mitarbeitenden sind größtenteils bekannt und aufgrund der Größe des Unternehmens sind für fast alle denkbaren Themen auch die passenden Expertisen verfügbar, aber diese sind zu einem gegebenen Zeitpunkt meistens bereits in anderen Projekten eingesetzt. Für die Zusammenstellung von neuen Projekten sind also Diskussionen zu führen und Kompromisse zu finden, welche die Interessen der Mitarbeitenden sowie die Interessen von laufenden und zukünftigen Projekten möglichst optimal berücksichtigen.

Obwohl dieser Prozess schwierig ist und viel Geschick erfordert, ist es schon als positiv zu werten, wenn alle dazu notwendigen Vorbedingungen erfüllt sind:

  • Der Arbeitgeber hat akzeptiert, dass eine Spezialisierung von Software-Entwickelnden sinnvoll ist und unterstützt diese aktiv durch entsprechende Schulungsmaßnahmen. Speziell bei komplexeren Themen muss auch akzeptiert werden, dass eine Expertise zum Beispiel in AWS oder Azure nicht in einem kurzen Schnupperkurs zu erwerben ist, sondern dass hier einige Wochen (oder Monate) zu investieren sind. Diese Investition lohnt sich aber für alle Beteiligten.
  • Der Arbeitgeber bemüht sich, spezialisierte Mitarbeitende in Projekten unterzubringen, welche diese Spezialisierung auch benötigen. Wenn eine erarbeitete Spezialisierung nicht direkt im Anschluss in einem relevanten Projekt eingesetzt wird, kann sich das erworbene Wissen nicht verfestigen und verschwindet evtl. wieder. Dies ist für den Arbeitgeber höchst ineffizient und für die Mitarbeitenden demotivierend. Gerade bei Cloud-Plattformen ist eine erfolgte Einarbeitung eine wertvolle Investition, die auch genutzt werden muss.
  • Informationen über die Stärken und Neigungen der Mitarbeitenden sind vorhanden, werden aktuell gehalten und stehen dort zur Verfügung, wo Projekte besetzt werden müssen.
  • Für stark nachgefragte Spezialisierungen werden Lernpfade mit passenden Schulungsmaßnahmen identifiziert und dokumentiert.

Diese Situation ist aber erst einmal herzustellen und aufrecht zu erhalten. In meinem Umfeld haben sich dafür folgende Maßnahmen bewährt:

  • Die Einführung einer Datenbank für die Fähigkeiten und Interessen der Mitarbeitenden. Mittels einer Intranet-Anwendung können die Mitarbeitenden ihre Fähigkeiten selbst aktuell halten (und sehen selbstverständlich nur die eigenen Daten). Führungskräfte können in dieser Datenbank gezielt nach Fähigkeitsprofilen suchen.
  • Die permanente Beobachtung und Hochrechnung des Bedarfs an Expertisen und die Ausrichtung des internen Ausbildungsprogramms an diesem Bedarf.
  • Die Information der Mitarbeitenden über den erwarteten Wissensbedarf und die verfügbaren Weiterbildungsmaßnahmen.

Obwohl der Nutzen dieser Maßnahmen deutlich spürbar ist, stellt die optimale und zeitnahe Besetzung von Software-Entwicklungsprojekten immer noch eine Herausforderung dar. Vielleicht spüren wir hier auch, dass die Software-Entwicklung überhaupt erst ein paar Jahrzehnte lang existiert. Andere Ingenieursdisziplinen sind bereits Jahrhunderte oder Jahrtausende aktiv und konnten entsprechend viele Erfahrungen sammeln. Diese Ingenieursdisziplinen zeigen meist eine stärkere Differenzierung in verschiedene Richtungen, die sich auch in unterschiedlichen Ausbildungspfaden ausdrückt. Das Resultat ist dann ein Spektrum aus verschiedenen Berufsbildern ohne den Anspruch, dass eine einzige Person alle Berufsbilder gleichzeitig abdecken muss.

Ist es an der Zeit, die Software-Entwicklung in unterschiedliche Berufsbilder zu gliedern?

Angesichts der eingangs beschriebenen, fast schon exponentiellen Vergrößerung des verlangten IT-Wissens, ist es nicht vielleicht an der Zeit, auch die Software-Entwicklung in unterschiedliche Berufsbilder zu gliedern? Vor etwa zwanzig Jahren hörte ich auf einer Konferenz einen Vortrag eines Vertreters der Luftfahrtindustrie, der die Komplexität eines (damals) modernen Großraum-Passagierflugzeugs mit der von größeren Softwaresystemen verglich. Die Konstruktion eines solchen Flugzeugs erfordert aber eine Vielzahl von stark spezialisierten Expertisen. Stellen wir uns vor, heutige Flugzeuge würden von einem oder mehreren Teams von nicht weiter spezialisierten "Flugzeugbaukräften" konstruiert. Analog zu unserer aktuellen Herangehensweise an Software-Projekte würden diese "Flugzeugbaukräfte" die Flugzeuge nicht nur entwerfen und konstruieren, sondern auch "betreiben", also zum Beispiel betanken, beladen und auch als Fluglotsen agieren. Wäre es attraktiv, diesen Beruf zu ergreifen? Würden wir mit solchen Flugzeugen noch fliegen wollen? Der Vergleich mag zunächst abstrus erscheinen, aber je länger ich darüber nachdenke, desto mehr Parallelen sehe ich zwischen diesen zwei Industrien, obwohl sich die aktuellen Vorgehensweisen in beiden Bereichen stark unterscheiden.

Bei meinem Arbeitgeber gibt es momentan in einem Geschäftsbereich den konkreten Plan, zwei Gruppen von Expertinnen und Experten zu den Themengebieten "Cloud-Anwendungsarchitektur" und "Cloud-Infrastruktur" zu bilden. Während die einen in der Lage sind, funktionale und nicht-funktionale Anforderungen auf performante, skalierbare, robuste und sichere Software-Architekturen auf Cloud-Plattformen abzubilden, beherrschen die anderen konkrete Cloud-Plattformen im Detail, beraten bei Architekturentscheidungen und können Cloud-Architekturen konfigurieren und umsetzen. Diese Gruppen mit verschiedenen Expertisen unterstützen insbesondere bei der Initialisierung von Projekten, stehen danach aber bei Bedarf immer beratend zur Verfügung.

Diese Gruppen von Expertinnen und Experten sind noch im Aufbau und müssen sich in der Praxis noch bewähren, aber wir versprechen uns dadurch einen effizienteren Einsatz unserer derzeit noch nicht im Überfluss vorhandenen Cloud-Fachkräfte und vielleicht auch eine Entlastung der Mitarbeitenden von der Erwartungshaltung, schlicht jederzeit alles können zu müssen. Vielleicht ist dies auch ein erster Einstieg in die Herausbildung von differenzierten Berufsbildern in der Software-Entwicklung. Hierzu sind aber sicher noch viele Diskussionen erforderlich und vielleicht sieht die Lösung der beschriebenen Probleme auch ganz anders aus. Auch mir ist der Wunsch, alle Aspekte eines Software-Projekts beherrschen zu wollen nicht fremd, gerade auch im Sinne der "Software-Craftsmanship" [1]. Dem gegenüber steht aber die aktuelle und vermutlich noch steigende Komplexität von Software-Systemen. Die Software-Entwicklungsindustrie und insbesondere die Gemeinschaft der Software-Entwickelnden wird hier weiterhin Lösungen finden müssen.

Quellen
  1. McBreen, P. (2002): Software Craftsmanship - The New Imperative. Upper Saddle River, NJ: Addison-Wesley.

Autor

Andreas Wickner

Andreas Wickner ist Lead IT Consultant bei der msg systems ag und dort in der Branche Automotive & Manufacturing tätig. Als erfahrener Software-Architekt hat er viele komplexe und verteilte Software-Systeme mitgestaltet.
>> Weiterlesen
Das könnte Sie auch interessieren
Kommentare (0)

Neuen Kommentar schreiben