Softwareentwicklung ist ein Lernprozess

Seit nunmehr 15 Jahren werde ich mit der Entwicklung von Software betraut und verfolge den Prozess von der Idee zum fertigen Programm aufmerksam. Und wenn ich eins in dieser Zeit beobachten konnte, dann dass der Softwareentwicklungsprozess „anders“ ist als die meisten anderen Herstellungsprozesse.

Daher möchte ich im Folgenden einige Aspekte der Softwareentwicklung beleuchten, um eine neue Sichtweise auf diesen Prozess aufzuzeigen. Sie soll helfen ihn besser zu verstehen und gleichzeitig anregen geeignetere Maßnahmen zu Produktivitätssteigerung zu finden.

Softwarenentwicklung als Produktionsprozess

Betrachtet man die Softwarenentwicklung als reinen Produktionsprozess, so wird der Rohstoff (die Spezifikation) von den Produktionsmitteln (Programmierern) zum Produkt (Programmcode) verarbeitet. Der so entstehende Programmcode wird üblicherweise in „Zeilen“ (bzw. ELOC) gemessen. Es lässt sich sogar feststellen, dass ein Programmierer durchschnittlich eine gewisse Menge an Programmcode pro Tag erzeugt, die man als durchschnittliche Leistung interpretieren kann. Dies bestärkt nur den Eindruck, man sei hier in der Produktionswirtschaft gut aufgehoben.

Neben dem Function-Point-Verfahren ist COCOMO ein etabliertes Schätzverfahren für den Aufwand bei Softwareprojekten. Laut COCOMO benötigt ein durchschnittliches Team für ein mittelschweres Projekt mit 10.000 Zeilen Programmcode in etwa 40 Mannmonate (= 152 Stunden). Berücksichtigt man, dass etwa nur ein Drittel der Zeit für die eigentliche Implementierung investiert wird, erzeugt ein Programmierer durchschnittlich 40 Zeilen Programmcode pro Tag.

Es dürfte klar sein, dass es nicht daran liegt, dass Programmierer langsam tippen. Die reine Tipparbeit nimmt nur einen Bruchteil der täglichen Arbeitszeit ein.

Was macht der Programmierer den ganzen Tag?

Die Vermutung liegt nahe, dass neben dem reinen Programmcode noch weitere Nebenprodukte entstehen, deren Aufwand hoch ist. An Auswahl mangelt es nicht:

• Dokumentationen
• Konzeptskizzen und Diagramme
• Testfälle

All dies ist es ebenfalls nicht. Das Schreiben von Testfällen benötigt pro 100 Zeilen Code deutlich weniger Zeit als das Schreiben von 100 Zeilen des eigentlichen zu testenden Programmcodes. Für Konzeptskizzen und Diagramme gilt gleiches wie für den Programmcode. Das reine Tippen oder Zeichnen des Ergebnisses dauert nur einen Bruchteil der investierten Zeit.

Diese Phänomen ist relativ einfach zur erklären: Es entsteht ein nicht sichtbares Nebenprodukt: Wissen. - Dieses Wissen bzw. die gewonnenen Erkenntnisse werden mühsam erarbeitet und münden letztlich im Programmcode oder in Konzepten. Sie bilden die notwendige Grundlage, um die sichtbaren Ergebnisse liefern zu können.

Besonders auffallend ist die Verteilung der investierten Zeit. Die meiste Zeit wird mit der Erlangung von Wissen verbracht und nur ein geringer Teil wird mit der tatsächlichen Niederschrift belegt.

Softwareentwickler verbringen also die meiste Zeit ihres Tages mit lernen.

Was gibt es zu lernen?

In der ständig wachsenden Flut an neuen Klassen, Modulen, Frameworks und Systemen wird der Programmierer mit immer wieder neuen Umgebungen konfrontiert. Er muss lernen welche Schnittstellen ihm zur Verfügung stehen, wie diese angesprochen werden, welche Konventionen einzuhalten sind und wie das System auf seine Änderungen reagieren wird. Dabei helfen ihm unter Anderem Dokumentationen, das Internet und die Kollegen. Dieses externe Wissen kann nicht so einfach wie ein Hammer verwendet werden. Das eigentlich bereits vorhandene Wissen muss verinnerlicht werden, um nutzbar zu sein. Es ist hier ein Wissenstransfer nötig: Lernen. Dieser Prozess braucht einige Zeit.

Ein Programmierer lernt auch viel nach dem Prinzip des „trial and error“. Auswirkungen von Änderungen sind nur schwer vorher abschätzen. Die Komplexität von Programmen oder gar ganzen Systemen lässt sich praktisch nicht mehr ganzheitlich erfassen. Vielmehr können Probleme nur noch partiell gelöst werden und sollen nach Möglichkeit keine anderen funktionierenden Systemteile beeinflussen. Es müssen immer wieder kleine „Tests“ durchgeführt. Diese einfachen Funktionstests sollen ein schnelles Feedback geben, ob das Programm überhaupt auf diese Weise funktionieren kann oder ob man sich auf einem Irrweg befindet, dessen Weiterverfolgung verlorene Zeit wäre

Sollte das Lernen nicht vorher passieren?

Software hat eine wunderbare Eigenschaft: Sie kann wiederverwendet werden. Im Gegensatz zum Handwerker, der durch unzählige Wiederholungen den Herstellungsprozess eines Produktes immer weiter verbessert, wiederholt der Programmierer seine Arbeit im Idealfall nie. Denn bereits bestehende Programmteile müssen nicht noch einmal erstellt werden.

Das hat aber eine weitreichende Konsequenz: Es bedeutet, dass jeder noch zu schreibende Programmcode vorher nicht existiert hat. Er ist somit für den Entwickler neu und unbekannt. (Andernfalls hätte er bestehenden Code verwenden können.)

Damit bewegt sich der Entwickler per Definition stets auf unbekanntem Terrain und erschließt Neuland. Und die dominanteste Funktion in diesem Prozess ist das Beobachten, Lernen und Verstehen um geeignete Handlungen (Programmzeilen) ergreifen zu können.

Wirtschaftliche Konsequenzen

Programmierer leben bereits eine Weile in betrieblichen Umfeldern, die das Lernen eher als abnehmenden Faktor betrachten, der durch das eigentliche Arbeiten abgelöst werden sollte:

• Ausbildung (schulisch, 100%)
• Einarbeitung (im Betrieb, meist wenige Monate ca. 50%)
• Fortbildung (1-2 Wochen im Jahr, weniger als 5%)

Dies erzeugt eine Situation, in der Lernen zwar toleriert aber auch argwöhnisch betrachtet wird. Um nicht ins schlechte Licht gerückt zu werden, passen Programmierer ihr Verhalten an. Sie verschleiern, dass sie lernen:

• Begriffe werden uminterpretiert: Ausprobieren wird zum „Testen“ umgemünzt. Dieser Begriff ist wesentlich unkonkreter und die Akzeptanz für den Begriff höher, da Tests auch als qualitätssteigernde Maßnahmen bekannt sind.
• Bestimmte Quellen werden gemieden: Das Lesen von Dokumentationen, SDK Hilfen und Quellcode wird eher akzeptiert als Internetrecherchen oder gar das Gespräch mit dem Kollegen. Die effizienteren Quellen werden gemieden, um den Verdacht des Zeitvertreibs auszuräumen. Stattdessen wird der Mehraufwand beim Lernen durch „ungefährlichere“ Quellen in Kauf genommen.
• Das Lernen wird vorzeitig abgebrochen: Häufiges Prüfen von Ergebnissen zwingt Programmierer das Lernen zu unterbrechen und mit der Erzeugung von Programmcode zu beginnen. Es wird selten unproblematisch verlaufen, wenn bereits 10% der Projektlaufzeit verbraucht sind, bis dahin aber „nur“ Konzepte stehen. Damit eingehandelte spätere Umbaumaßnahmen und Änderungen werden hingegen eher akzeptiert.

Die wirtschaftlichen Auswirkungen auf ein Unternehmen dürften klar sein. Ihr Gegenwert lässt sich jedoch nur schwer beziffern, da es hier kaum veröffentlichte Zahlen geben wird.

Es ist jedoch nicht haltbar, dass eine wesentliche Tätigkeit und damit ein Hauptaspekt der Softwareentwicklung ausgeblendet oder gar tabuisiert wird und sich so jeglichen Verbesserungsmaßnahmen entzieht.

Wie kann man die Softwareentwicklung verbessern?

Möchte man die Softwareentwicklung verbessern, muss man sie als das betrachten, was sie ist: ein Lernprozess. Die Pädagogik bzw. Didaktik beschäftigen sich seit Langem mit der Verbesserung von Lernprozessen. Hier kann man auf bewährte Methoden und Maßnahmen zurückgreifen.

Angewendet auf die Softwareentwicklung sollten zunächst einmal die negativen Faktoren aus dem Weg geräumt werden, die das Lernen behindern:

• Atmosphäre: Eine leise und ungestörte Umgebung ist wichtig.
• Aufgaben sollten bedarfsgerecht sein. Sie sollten weder überfordern noch unterfordern; sonst entsteht Frust.
• Lernen heißt Fehler machen. Es muss Raum für Fehler bleiben, sonst lähmt die Angst vor dem Versagen den Lernprozess.
• Pausen sind keine unproduktive Zeit. Entwickler machen von sich aus kaum Pausen, wenn sie im „Flow“ sind. Sie nutzen gerne diese Momente der Klarheit, um viel zu schaffen. Manchmal brauchen sie aber auch Abstand, um wieder Klarheit zu bekommen. Fehlen diese Pausen, können sich Denkblockaden lange hinziehen und kosten im Endeffekt nur mehr Zeit. Das wissen Entwickler und sind eher frustriert, wenn sie nicht „frei“ Pausen machen können. (Viele Pausen können auch ein Zeichen von Über-/Unterforderung sein.)
• Antreiben: Entwickler unter Druck setzen ist kontraproduktiv. Es erhöht den Stress, der sich negativ auf die Konzentration auswirkt. Außerdem sind Programmierer, wie bereits erwähnt, Autodidakten. Sie haben bereits freiwillig das gelernt, was sie können. Mangelnde Selbstdisziplin ist hier eher seltener das Problem.

Anschließend kann man sich daran machen, den Lernprozess zu fördern.

1. Stellen Sie den Nutzen und die Bedeutung der Software für das Unternehmen oder den Kunden dar. Wer das Gefühl hat an etwas Wichtigem beteiligt zu sein, ist interessierter und engagierter.
2. Zum Lernen geeignete Dokumentationen schaffen
   • Sie sollten eher Tutorials sein. (Ein gutes Beispiel gibt die Homepage von jQuery.) Sie sollten Beispielaufrufe und -ergebnisse enthalten, die ein anfängliches „rumprobieren“ ersparen.
   • Sie sollten Lebenszyklen und Abläufe im System darstellen. Oft findet man nur statische Betrachtungen des Systems, die wenig über das offensichtliche hinaus gehen. Die Dynamik ist jedoch besonders schwer zu erfassen. Daher sollte sie besonders anschaulich dokumentiert werden.
   • Halten Sie Annahmen und Entscheidungen nach. Diese sind nicht in den Anforderungen enthalten und erleichtern es später hinzukommenden Entwicklern Zusammenhänge zu erfassen.
   • Planen Sie mindestens 10% der Entwicklungszeit für Dokumentationen ein. Weniger sollte ein Warnsignal sein.
   • Dokumentationen müssen bekannt gemacht werden und auffindbar sein. Gerade in größeren Unternehmen sollte das Auffinden von Dokumentationen trainiert werden.
3. Nutzen Sie graphische Darstellungen des Systems. Lassen Sie diese in verschiedenen Detailierungsstufen erstellen. Der große Überblick ist ebenso wichtig wie das Zusammenspiel im Detail. Das hebt und festigt die gemeinsame Vorstellung vom System. (Ein Bild sagt mehr als tausend Zeilen Code.)
4. Lehren heißt lernen. Fördern Sie, dass Kollegen untereinander Wissen und Erfahrungen vermitteln. Und zwar auch über das übliche „Einarbeiten“ hinaus. Denn so wird nicht nur neues passives Wissen bei den Kollegen aufgebaut, sondern auch der Lehrende festigt sein Verständnis und arbeitet sicherer, schneller und macht weniger Fehler, die sonst Zeit kosten.
5. Lernen muss interessant bleiben. Oft sind Aufgaben nur ungünstig verteilt. Unterstützen Sie die Neigungen ihrer Entwickler, die so Vorwissen und Motivation einbringen.
6. Verantwortung heißt nicht selber machen. Auch ihre Entwickler müssen nicht jedes Modul, mit dem sie betraut wurden, alleine erstellen. Zeigen Sie Wege auf, wie die Entwickler Aufgaben untereinander abgeben können. So übernehmen sie mehr Verantwortung für ihre Aufgaben.