Die Ausbildung von Softwareentwickler:innen

Wir brauchen qualifizierte Softwareentwickler:innen: Die schiere Menge von Anforderungen an IT-Systeme nimmt schneller zu als der Fachkräftebestand. Entsprechend leidet die Qualität, ausgerechnet wenn immer mehr kritische Prozesse von IT gesteuert werden. Es wäre also nicht schlecht, wenn noch mehr Menschen qualifiziert Software entwickeln könnten.

Auch umgekehrt ist das wünschenswert: Programmieren ist eine konstruktive, kreative Tätigkeit, die Freude macht, die Lösung vieler Probleme erst ermöglicht und auch in der Auseinandersetzung im Team und mit Kund:innen zwischenmenschliche Fähigkeiten fordert und fördern kann. Wenn wir also mehr Softwareentwickler:innen benötigen, dann müssen wir sie ausbilden. Aber wie?

Das Narrativ der Ausbildung in der Softwareentwicklung

Das Narrativ der Ausbildung in der Öffentlichkeit und weiten Teilen der IT sieht so aus:

1. „Junge Menschen für IT begeistern“
2. Werkzeuge für das Programmieren bereitstellen
3. Programmbeispiele vorstellen

Wer genau hinschaut, kann sehen, dass dieses Konzept eigentlich darauf baut, dass sich die Lernenden das Programmieren selbst beibringen. Ein Blick in nahezu jedes gängige Buch zum Programmieren illustriert das Prinzip. Ein Programmbeispiel, das typischerweise einige Features einer Programmiersprache zeigt, wird erläutert, gefolgt von der Aufforderung „Und jetzt Du!“. Das Konzept funktioniert für einige zumindest, nämlich gerade die, die tatsächlich dann auch Softwareentwickler:innen werden.

Allerdings gibt es zwei Probleme mit dem Konzept:

• Die Lehre über Beispiele ist keine Anleitung zum systematischen Vorgehen. Entsprechend sehen wir in vielen Softwareprojekte jede Menge Spaghetti-Code und schlechte Architektur.
• Es erreicht viele Lernenden nicht, die frustriert aufgeben, ähnlich wie das in der Mathematik verbreitete „Ich kann kein Mathe“.

Das erste Problem verursacht technische Probleme, das zweite soziale, weil es die Vielfalt der Softwareentwickler:innen-Community einschränkt: Wer sich Programmieren selbst beibringen soll, braucht Selbstvertrauen und Experimentierfreude, die materielle Absicherung bedingen und damit überwiegend nur bestimmten sozialen Schichten vorbehalten sind.

Diese Problematik findet sich insbesondere in Ausbildungsansätzen, die auf „Konstruktionismus“ beruhen. Diese Idee – propagiert von Seymour Papert, dem Erfinder der Programmiersprache LOGO – besagt (stark verkürzt), dass insbesondere Kinder sich Fertigkeiten und Wissen selbst aneignen, wenn man ihnen nur Zugang zu Werkzeugen und Information verschafft. Konstruktionismus war die Grundlage für das One-Laptop-per-Child-Projekt (OLPC), das allerdings didaktisch (und noch anderweitig) krachend scheiterte: In der Breite scheint der Konstruktionismus einfach nicht zu funktionieren. Dort fehlt es übrigens auch an einer systematischen Methodik. Die Spätausläufer dieser Idee sind leider inzwischen die vielerlei Grundlagen für den deutschen Informatikunterricht und für die unzähligen Roboter-im-Unterricht-Initiativen, die „junge Menschen für IT begeistern“ sollen.

Auf dem Weg zur besseren Ausbildung für Softwareentwickler:innen

Aus einer Vielzahl von Gründen – Vielfalt, Gerechtigkeit, steigende Anforderungen an die IT – sollten wir also dafür sorgen, dass das mit der Ausbildung besser funktioniert. Gute Ideen allein reichen nicht dafür: Wir müssen diese auch kritisch evaluieren und mit Hilfe der Evaluation inkrementell verbessern. (Und dabei reicht es nicht, nur die erfolgreichen Lernenden zu bitten, irgendwelche Fragebögen auszufüllen.)

Mit der Problematik haben sich insbesondere das amerikanische PLT-Projekt unter Leitung von Matthias Felleisen (USA) und DeinProgramm (Deutschland) beschäftigt, das zweite ein Ableger des ersten, der 1999 mit einer Reihe von Anfängervorlesungen an der Universität Tübingen bei Prof. Herbert Klaeren und mir begann. Wir waren damals vom Eifer guter Ideen beseelt – nämlich funktionale Programmierung und die Programmiersprache als Grundlage für die Anfängerausbildung zu etablieren.

Viel sprach damals für diesen Ansatz: Das MIT hatte ähnliches bereits in den späten 80er Jahren als Anfängerausbildung etabliert und das großartige Buch Structure and Interpretation of Computer Programs produziert. Nach anfänglichem Enthusiasmus – vielen Studierenden gefiel der Ansatz – mussten wir feststellen, dass die Vorlesung viele Studierende nicht befähigte, eigenständig zu programmieren. (Die Ergebnisse waren im Vergleich mit anderen Anfängervorlesungen nicht schlecht, aber für uns nicht gut genug. Und tatsächlich ist das MIT-Buch ein gutes Buch, nur eben nicht für die Anfänger:innenausbildung.)

Wir begannen also einen zunächst schmerzhaften Prozess der Beobachtung, Auswertung und inkrementellen Verbesserung, der nahezu alle Lehreinheiten der ursprünglichen Vorlesung zum Opfer fielen. Gleichzeitig bemerkten wir, dass viele unserer Beobachtungen und Verbesserungen mit denen des Projekts Program by Design zusammenfielen, das 2001 das Buch „How to Design Programs“ produzierte.

Die wichtigsten davon waren diese hier:

• Schöne Beispiele helfen nichts, wenn man nicht nachvollziehbar erklären kann, wie sie zustande gekommen sind. Das bedeutet, dass man auf explizit benannte Techniken verweist, die Lernende im Lehrmaterial einfach wiederfinden kann. Als Resultat entwickelten wir sogenannte Konstruktionsanleitungen – das Pendant zu den design recipes aus „How to Design Programs“ – die das Programmieren in ein nachvollziehbares, klar definiertes Korsett einbetten.
• Wir waren überzeugt davon, dass die Programmiersprache Scheme, die in „Structure and Interpretation of Computer Programs“ verwendet wird, optimal für die Lehre ist, weil sie klein und regulär aufgebaut ist. Diese Eigenschaften helfen zwar, sind aber nicht ausreichend: Entscheidend sind auch gute Fehlermeldungen und eine direkte Entsprechung von didaktischen Konzepten zu Elementen der Programmiersprache. So entstand analog zu den *SL-Sprachen von „How to Design Programs“ die DeinProgramm-Sprachen mit vielen Änderungen und Verbesserungen gegenüber Scheme.
• Programmierumgebungen für professionelle Programmierer:innen sind für Anfänger:innen zu komplex. Entsprechend verwendeten wir schon früh die vom PLT-Projekt entwickelte Umgebung DrRacket.

Geblieben von der Vorlesung von 1999 ist letztlich nur die Grundlage der funktionalen Programmierung, die sich mittlerweile nicht nur für die Lehre sondern auch für die praktische Entwicklung als besonders effektive Basis herausgestellt hat.

Konstruktionsanleitungen für Softwareentwickler:innen

Der didaktische Ansatz der Konstruktionsanleitungen wird unbedarften Lesenden extrem bürokratisch vorkommen, weil er wirklich alles vorkaut und vorschreibt, was möglich ist und nahezu mechanistisch Programmelemente aus den vorigen Schritten herleitet. (Intern firmiert er als „deutsche Beamtenmethode der Programmierung.“)

Die Konstruktionsanleitung gehen von der Datenmodellierung aus und leiten daraus das Gerüst für das Programm fast schon mechanisch ab. Die Datenmodellierung beginnt mit einer stilisierten Beschreibung der Daten. Beispiel:

„Ein Festessen besteht aus Vorspeise, Hauptgang und Nachspeise.“

Die Formulierung „besteht aus“ bedeutet, dass es sich um sogenannte zusammengesetzte Daten handelt. Das steht im Gegensatz zu Formulierungen wie:

„Ein Tier kann ein Gürteltier oder ein Papagei sein.“

Hier ist das operative Wort „oder“, was auf sogenannte gemischte Daten hinweist. Auf diese Art wird das gesamte Datenmodell „dekliniert“ und dann direkt in Code übersetzt. Aus der Form der Daten ergibt sich direkt das Code-Gerüst für die Funktionen, welche die Daten verarbeiten. Erst am Schluss muss die Programmiererin wirklich Domänenwissen einbringen, die Schritte davor bauen fast mechanisch aufeinander auf. Entsprechend ist der Ansatz systematisch, weil er nachvollziehbar zu korrekten Ergebnissen führt.

Diese Methode ist für die meisten Lernenden nachvollziehbar – insbesondere diejenigen, die sonst Schwierigkeiten haben, sich solche Fertigkeiten selbst beizubringen. In Richtung einer breiteren und systematischen Programmierausbildung für eine große Vielfalt von Lernenden ist der Ansatz also zumindest ein Schritt in die richtige Richtung.

Entwicklung und Erkenntnisse haben wir seinerzeit in einer Reihe von Fachaufsätzen dokumentiert, die auf der Projektseite https://www.deinprogramm.de/ verlinkt sind, ebenso wie ein in Entstehung befindliches kostenloses e-Book.

PS: Ich verließ 2003 die Universität und begann Jahre später, professionelle Schulungen in Softwareentwicklung und -architektur zu unterrichten. Dabei stellte ich mit Erstaunen fest, dass der DeinProgramm-Ansatz in Gänze auch für solche Schulungen funktioniert, obwohl er für Anfänger:innen entwickelt wurde.

Hinweise:

Interessieren Sie sich für weitere Erfahrungen aus der Praxis? Testen Sie unseren wöchentlichen Newsletter mit interessanten Beiträgen, Downloads, Empfehlungen und aktuellem Wissen.

t2informatik entwickelt und modernisiert Software als Dienstleister. Ein Klick hier und Sie erfahren mehr.