Dieser Artikel stellt Informationen zur Diskussion, die 2013 in einer Umfrage zur Programmierlehre erhoben wurden, und ergänzt diese um einige Zahlen, die der Autor in seiner eigenen Programmierlehre an zwei deutschen Hochschulen (einer Uni und einer Fachhochschule) gesammelt hat. Auf Basis die‐ ser Zahlen sowie eigener Beobachtungen ergeben sich einige Fragen zum Thema Programmierlehre. Programmieren ist das Handwerkszeug der Softwaretechnik (Ludewig, 2010), die Programmierlehre bildet somit das Rückgrat jedes Informatikstudiums. Trotz dieses Stellenwertes wird dem Thema Programmieren traditionell auf Konferenzen zum Thema Software Engineering wenig Aufmerksamkeit geschenkt. Auf den SEUH‐Tagungen der letzten 10 Jahre hat sich dies etwas verbessert, indem zunehmend auch Programmierthemen diskutiert wur‐ den (Heuer et al., 2011; Langhoff et al., 2015; Schmedding et al., 2015). Dennoch haftet der grundständigen Programmierlehre häufig der Ruch des hemdsärmeligen, wenig wissenschaftlichen und teilweise sogar trivialen Anteils des Informatik‐Studiums an. Um dem bewusst entgegen zu wirken, wird in diesem Beitrag nicht mehr der Begriff Programmierausbildung benutzt, wie in früheren Artikeln (Schmolitzky, Züllighoven, 2007; Schmolitzky, 2013), sondern der passendere Begriff Programmierlehre. Das Thema Programmierlehre befindet sich stärker im Fluss, als dies von vielen vermutet wird. Pro‐ grammieren ist eine Kunst, entsprechend ist auch die Programmierlehre eine Kunst, die wir bei weitem noch nicht so gut beherrschen, wie es der Wich‐ tigkeit der Disziplin angemessen wäre. Nach wie vor wissen wir zu wenig darüber, wie eine angemessene Programmierlehre aussehen sollte. Der Autor hat als ersten Schritt einer Klärung nach der SEUH 2013 die Teilnehmer der Tagung zur Teilnahme an einer Erhebung aufgefordert, in der der aktuelle Stand der Programmierlehre an deutschsprachigen Hochschulen ermittelt werden sollte. Die Randbedingungen und Ergebnisse dieser Umfrage werden im nächsten Abschnitt präsentiert. Abschnitt 3 stellt anhand konkreter Zahlen eigene Erfahrungswerte in der Programmierlehre des Autors zur Diskussion und Abschnitt 4 diskutiert weitere Aspekte, die dem Autor in Bezug auf Programmierlehre wichtig erscheinen. Im Anschluss an die SEUH 2013 in Aachen hat der Autor eine E‐Mail‐Umfrage zur einführenden Programmierlehre unter den Teilnehmern der Tagung durchgeführt. Der Rücklauf umfasste 22 Antworten von Lehrenden an deutschsprachigen Hochschulen zu ca. 50 Bachelor‐Studiengängen. Zum Vergleich: laut den Webseiten der GI ist ein Studium für einen Bachelor‐Abschluss mit Informatik‐Anteil allein in Deutschland an ca. 150 Hochschulen möglich, in fast 800 Studiengängen. Eine erste Auswertung der Antworten präsentierte der Autor informell in einem Vortrag auf der SEUH 2015 in Dresden. Im Folgenden werden die Ergebnisse erstmals schriftlich zusammengefasst und bewertet.
Die Umfrage zielte darauf, in Bachelorstudiengän‐ gen mit hohem Informatik‐Anteil den Umfang, die Schwerpunkte und die Probleme in der Programmier‐ lehre zu erfassen. Konkret wurde nach Pflichtmodu‐ len, vermittelten Programmierparadigmen und ver‐ wendeten Programmiersprachen gefragt (siehe An‐ hang A). Die Motivation des Autors war unter ande‐ rem, seinen subjektiven Eindruck, dass die Pro‐ grammierlehre an deutschen Hochschulen oft stief‐ mütterlich behandelt und/oder kritisch von den „Abnehmern“ (Lehrende höherer Semester, Arbeit‐ geber) beurteilt wird, durch systematisch erhobene Hinweise zu bestätigen.
Die Auswertung der Antworten zeigte einige Prob‐ leme der Umfrage selbst auf. So war die Frage nach „Modulen zur Programmierung“ offensichtlich nicht scharf genug gestellt, denn etliche Antworten nannten alle Module, in denen auch programmiert wird (wie Betriebssysteme oder Datenbanken), nicht nur solche, in denen die Programmierung selbst ex‐ plizit vermittelt wird.
Ein weiterer Schwachpunkt war die Frage nach dem Umfang in SWS. Diese Kenngröße wird an deutschen Hochschulen ausgesprochen uneinheit‐ lich verwendet und ist wenig aussagekräftig, insbe‐ sondere seit der Bologna‐Reform. Für die Studieren‐ den wurde die Währung SWS durch die neue Wäh‐ rung Leistungspunkte (LP) bzw. Credit Points (CP) ersetzt, die explizit die Aufwände der Studierenden bemessen soll. Ein generelles Problem (nicht nur dieser Umfrage) ist, dass die Umrechnung von SWS in LP mit hohem kreativen Potenzial auf sehr unter‐ schiedliche Weise erfolgt. Vergleiche werden damit noch mehr erschwert.
Insgesamt kann aus den folgenden Ergebnissen nur ein erster Eindruck gewonnen werden.
Die Umfrage lieferte Daten zu 48 Studiengängen, 18 davon an Universitäten und 30 an Fachhochschulen. Die häufigsten Studiengangsbezeichnungen sind In‐ formatik mit 12 Nennungen und Wirtschaftsinformatik mit neun Nennungen. Alle anderen Studiengänge tragen „Bindestrichnamen“, von Technischer Infor‐ matik und Medieninformatik (jeweils drei Nennun‐ gen) bis hin zu Informationslogistik oder Multimedia Marketing. Bemerkenswert ist der hohe Anteil an „Insidern“ unter den antwortenden Lehrenden: 21 von 22 sind selbst in der Programmierlehre aktiv. Umfang der einführenden Module Trotz stark heterogener Strukturen und Bezeichnun‐ gen bieten alle Studiengänge mindestens ein, meist zwei klar identifizierbare einführende Pflichtmodule zur Programmierung an. Der Umfang in Semester‐ wochenstunden (SWS) reicht dabei von 1+1 (Vorle‐ sung + Übung bzw. Praktikum) bis zu 4+4, von ho‐ hem Vorlesungsanteil mit wenigen Übungsstunden bis hin zu kurzen Vorlesungen mit starkem Übungs‐ anteil. Die fünf häufigsten Nennungen für Umfänge des ersten Moduls (M1) sind Abbildung 1 zu entneh‐ men, diese decken 42 der 48 Studiengänge ab. 20 15 10 5 0
imperativ oo funktional logisch Pflicht optional nicht
Das zweite Modul (M2) ist oft kleiner im Umfang, die fünf häufigsten Nennungen führt Abbildung 2 auf. 2+2 4+2 3+2 2+4 4+4
Erwartungskonform ist der hohe Übungs‐ bzw. Praktikumsanteil, nur sehr wenige Antworten (ca. 6%) beschrieben Module mit weniger als einem +2‐ Anteil.
Die Anzahl der Pflichtmodule zur Programmie‐ rung reicht von zwei bis zu sieben. Bei den reinen Informatik‐Studiengängen gibt es nur einen mit le‐ diglich zwei Pflichtmodulen, meist sind es drei oder vier. Bei den Wirtschaftsinformatik‐Studiengängen hingegen sind zwei Pflichtmodule der Normalfall, nur zwei der neun Studiengänge haben drei Pflicht‐ module. Programmierparadigmen und ‐sprachen In allen 48 Studiengängen gehören imperative und ob‐ jektorientierte Programmierung zur Pflicht. Funktionale Programmierung (FP) gehört nur in 13 Studiengän‐ gen zum Pflichtprogramm (9 davon an Unis) und ist in 8 Studiengängen optional, in 27 Studiengängen wird sie nicht angeboten, also in mehr als der Hälfte. Ein ähnliches Bild zeigt sich bei logischer Programmie‐ rung (LP): Sie ist Pflicht in 12 Studiengängen (8 da‐ von an Unis) und optional in 8, nicht angeboten wird sie in 28 Studiengängen (Abbildung 3). 15 10 5 0 60 50 40 30 20 10 0 den Einstieg in die Programmierung wird nur ein‐ mal genannt. Bei einem Einstieg mit funktionaler Programmierung (ausschließlich oder gemeinsam mit anderen Paradigmen: 4 Studiengänge) werden Haskell oder Scheme verwendet.
In M2 wird in 31 von 48 Studiengängen Java ver‐ wendet, alternativ kommen hier C, C++, Haskell, Scheme, Prolog und CHR zum Einsatz. In allen Stu‐ diengängen wird Java aber mindestens entweder im ersten oder im zweiten Semester eingesetzt, so dass jeder Student in seinem Studium Java kennenlernt. Zufriedenheit/Probleme Die überwiegende Mehrheit der Antwortenden zeigte sich zufrieden mit der an der eigenen Hoch‐ schule angebotenen Programmierlehre: 17 von 22 antworteten mit „klares ja“, „ja“ oder „eher ja“ (Ab‐ bildung 4). klares nein 1 klares ja
4 nein
1 eher nein 3 eher ja 8 ‐ Ersten Programmiererfahrungen
Abstimmung zwischen den Lehrenden (fünf Ant‐ worten): „Die Vorlesung Programmierung wird semesterweise wechselnd von verschiedenen Dozenten gehalten, die zum
entsprechend ist die Vorlesung mal sehr auf Algorithmen und Datenstrukturen konzentriert auf Kosten wichtiger
Kosten konzeptioneller Überlegungen. […]“ „Kein einheitliches Konzept unter den Dozenten verein‐ bar.“ „Die Programmierausbildung ist über viele Dozenten verteilt und wird nicht gemeinschaftlich geplant. Das Re‐ sultat ist ein Flickenteppich aus nicht aufeinander abge‐ stimmten Kursen, die vieles doppelt, widersprüchlich und/oder gar nicht behandeln.“ „Wir haben im Wechsel zwei sehr unterschiedliche Leh‐ rende, die sich in fast nichts einigen können. So steht IP gegen OOP, main‐Methodenprogrammierung gegen De‐ sign Patterns, Blockpraktikum gegen schriftliche Klausur usw.“ „Programmiertechniken werden losgelöst von Software‐ technik betrachtet und sind oft nicht mehr auf dem aktu‐ ellen Stand der Forschung. Die Programmierausbildung (vlt. Lehre allgemein) wird auch nicht als wichtiges Betä‐ tigungsfeld, sondern eher als lästige Pflicht oder als Mög‐ lichkeit zur Nachwuchsrekrutierung gesehen.“ Zu geringe Praxisnähe (vier Antworten): „Es besteht noch Verbesserungspotential bei der Unter‐ stützung der Programmieranfänger ohne Vorkenntnis‐ sen.“ „Die Programmierausbildung könnte praxisnäher sein.“ „Ich erachte vor allem die sehr geringe Programmierpra‐ xis, die in der Vergangenheit in XXX vorgesehen war und den großen Sprung zu YYY (3 Semester später), als ein signifikantes Problem. Von Studierenden, die kaum pro‐ grammieren konnten, wurde erwartet, dass sie direkt mit objektorientiertem Software‐Entwurf beginnen.“ „Trotz SoPra haben viele Studierende die grundlegenden Prinzipien nicht verstanden. Meiner Meinung nach liegt ein großes Problem darin, dass den Studierenden zwar das „Handwerkszeug“ mitgegeben wird, allerdings wer‐ den die Studierenden häufig alleine gelassen, wenn es um die Anwendung der erlernten Prinzipien geht. Insbeson‐ dere das Vorgehen um von einer Problemstellung auf eine konkrete Lösung, welche verschiedene einzelne „Techni‐
Probleme mit der Programmierlehre konnten über Freitexte mitgeteilt werden. Die im Folgenden voll‐ ständig aufgeführten Rückmeldungen können grob unterschieden werden in solche zu Problemen der Studierenden (Motivation, Zeiteinsatz) und zu Prob‐ lemen auf Seiten der Lehrenden (Organisation, Fo‐ kus, Praxisnähe). Probleme auf Seiten der Studierenden: „[…] Das größere Problem ist für mich aber, dass die Stu‐ dis zu wenig Präsenzübung haben (ist nun in XXX ver‐ stärkt geplant) und oft nicht genügend üben.“ „Wir haben eine zu hohe Durchfallquote (40‐50%). Stu‐ dierende halten Programmierung für „einfach“, sie fan‐ gen zu spät an, ernsthaft zu arbeiten.“ „Teilweise fehlende Motivation der Studierenden (Pro‐ grammierung gilt zu Beginn des Studiums vielfach neben
Beginn des Studiums verbreitet wenig Motivation zur selbständigen Arbeit und zum Experimentieren)“ „Eingangskompetenzen der Studierenden gar nicht vor‐ handen bzw. unzulänglich hinsichtlich: ‐ Abstraktionsvermögen ‐ Algorithmischem Denken ken“ der Programmierparadigmen kombiniert, zu kom‐ men, bleibt unklar. Die separierte, rein „technische“ Ver‐ mittlung der Programmierkonstrukte trägt sicherlich dazu bei, die Zusammenhänge aus dem Auge zu verlie‐ ren.“ Zu einseitige Lehre (zwei Antworten): „Mit FP und LP kommen unsere Studierenden aus‐ schließlich im Master in Berührung, wobei FP ausschließ‐ lich im Anwendungskontext gelehrt wird und nicht als grundsätzliches Paradigma. Da unsere beiden Studien‐ gänge dem Namen nach anwendungsorientiert sind, ist dies auch so gewünscht und sinnvoll ‐ schade ist es trotz‐ dem, da so wichtige Grundlagen zum Blick über den ob‐ jektorientierten Tellerrand nicht gelegt werden.“ „Im Moment läuft es auf eine sehr Java‐lastige Program‐ mierausbildung hinaus. Es ist noch nicht so klar, wo die
Dass die Mehrheit der antwortenden Lehrenden mit der angebotenen Programmierlehre zufrieden ist, überrascht nicht: fast alle Antwortenden sind selbst in der Programmierlehre aktiv. Offensichtlich haben nur Personen, die eine starke Bindung zum Thema Programmierlehre haben, die Mühe auf sich genom‐ men, die detaillierten Fragen (siehe Anhang 1) zu beantworten. Die vom Autor in einzelnen Gesprä‐ chen aufgefangene Unzufriedenheit mit den Pro‐ grammierfähigkeiten der Teilnehmer fortführender Veranstaltungen konnte so nicht systematisch er‐ fasst werden. Andererseits ist es für den Autor ein gutes Zeichen, wenn auf einer Software‐Enginee‐ ring‐Tagung eine starke Bindung zum Programmie‐ ren deutlich wird.
Im Rahmen seiner eigenen Lehrtätigkeit hat der Au‐ tor Erfahrungen mit mehr als zehn verschiedenen Studiengängen gesammelt, von denen er einen selbst mitgestaltet hat. Unter den Studiengängen waren Diplom‐, Bachelor‐ und Master‐Studien‐ gänge in zwei deutschen Bundesländern sowie einer in Australien.
An der Uni Hamburg hat der Autor vor allem in den Jahren 2005 bis 2013 die einführenden Program‐ mierveranstaltungen der neuen Bachelor‐Studien‐ gänge mit aufgebaut und durchgeführt (Schmolitzky, Züllighoven, 2007; Schmolitzky, 2013).
Nach seinem Wechsel an die HAW Hamburg im Jahr 2014 hat der Autor dort drei Einführungszyklen durchgeführt (bestehend aus Programmieren 1 und Programmieren 2 in den ersten beiden Semestern), in allen drei an der HAW Hamburg angebotenen Infor‐ matik‐Bachelor‐Studiengängen: in der Angewandten
In diesem Abschnitt werden drei Vergleiche vor‐ genommen: Als erstes zwischen den Teilnehmern an der Abschlussprüfung einer Programmierveranstal‐ tung des ersten Semesters an der Uni Hamburg, gruppiert nach ihren Studiengängen; die hohen Teil‐ nehmerzahlen lassen hier verallgemeinernde Rück‐ schlüsse zu. Der zweite Vergleich basiert auf einer Programmierprüfung, die der Autor sowohl an der Uni Hamburg als auch an der HAW Hamburg durchgeführt hat. Als drittes werden die genannten Programmierveranstaltungen an der HAW Ham‐ burg zwischen den erwähnten Studiengängen ver‐ glichen.
An der Uni Hamburg besteht die einführende Pro‐ grammierlehre aus den Modulen Softwareentwick‐ lung 1 und 2 (SE1 und SE2); an diesen Modulen war der Autor von 2005 bis 2013 maßgeblich beteiligt. In SE1 und SE2 gibt es Teilnehmer aus inzwischen fünf Bachelor‐Studiengängen: Informatik (Inf), Wirt‐ schaftsinformatik (WInf), Software‐System‐Entwicklung (SSE), Mensch‐Computer‐Interaktion (MCI) sowie Computing in Science (CiS). Hinzu kommen die Lehr‐ amt‐Studierenden (LA) sowie als weitere große Ziel‐ gruppen Mathematik‐ (MA) und Physik‐Studierende (PH) mit Nebenfach Informatik. In den Jahren 2009 (Start der Studiengänge SSE, MCI und CiS) bis 2013 hat der Autor bei der ersten Prüfung die Klausurer‐ gebnisse nach Studiengängen differenziert, so dass ein Ranking der Studiengänge nach der Durch‐ schnittsnote ihrer Kohorte möglich wurde. Die An‐ zahl der Klausurteilnehmer lag zwischen 290 (im Jahrgang 2009/2010) und 376 (2013/2014). Abbil‐ dung 5 zeigt die ermittelten Durchschnittsnoten in der Übersicht. 2009 2010 2011 2012 2013 1,5 2,5 2 3 3,5
Inf SSE
WInf MA
MCI PH
CiS LA
Neben der Idee, beim Blick auf diese Zahlen spontan einen Informatik‐Studiengang mit einem Titel wie „Physik‐Informatik“ gründen zu wollen, um talen‐ tierte Programmierer unmittelbar anzusprechen, fällt insbesondere auf, dass Wirtschaftsinformatik und Informatik auf Lehramt reproduzierbar die Schlusslichter in der Programmierlehre bilden. Die Zahlen sprechen hier eine sehr deutliche Sprache, eine Erklärung liefern sie nicht.
Die einführende Veranstaltung Programmieren 1 (PR1) in den Informatik‐Studiengängen an der HAW Hamburg hat ein ungewöhnliches Format: 6V+2P, also einen hohen Vorlesungsanteil und einen vergleichsweise geringen Praxisanteil. Formal be‐ steht sie aus zwei Modulen (Programmiermethodik und Programmiertechnik) und hat einen Umfang von 12 CP. In dieser Hinsicht ist sie somit doppelt so „groß“ wie die Veranstaltung SE1 der Uni Ham‐ burg, die lediglich 6 CP umfasst (bei 2V+2Ü). Da der Praxisanteil jedoch gleich groß ist, hat der Autor in seinem ersten PR1‐Durchgang an der HAW Ham‐ burg die gleichen Inhalte vermittelt wie in SE1 an der Uni, diese jedoch sehr viel ausführlicher in semi‐ naristischer Form mit den Studierenden im Vorle‐ sungsanteil diskutiert.
Ein weiterer Unterschied zur Uni besteht darin, dass in PR1 für beide Module je eine Prüfung statt‐ findet. Von diesen wird eine als klassische Klausur‐ prüfung durchgeführt, während die andere traditio‐ nell als Laborprüfung erfolgt (mit hohem technischen und organisatorischen Aufwand, der u.a. von den wissenschaftlichen Mitarbeitern des Departments Informatik erbracht wird). In der Laborprüfung müssen die Teilnehmer am Rechner unter kontrol‐ lierten Bedingungen (kein Internet‐Zugang) Pro‐ grammieraufgaben unter Zeitdruck lösen. Für den Autor war diese Form der Prüfung neu.
Unter den bisher genannten Bedingungen hat der Autor bewusst ein Experiment durchgeführt: Da die vermittelten Inhalte vergleichbar waren, hat er die exakt gleiche Klausurprüfung am Ende von PR1 durchgeführt, die er auch an der Uni im letzten SE1‐ Durchgang verwendet hatte; es handelte sich tat‐ sächlich sogar um dasselbe PDF‐Dokument.
Auf diese Weise konnte unter vergleichbaren Bedingungen (gleicher Dozent, gleiche Inhalte) ein direkter Vergleich zwischen Uni‐ und HAW‐Studie‐ renden erfolgen. Die erreichten Noten unterschie‐ den sich deutlich: Der Schnitt an der Uni lag bei 2,7, an der HAW bei 3,3.
Man könnte versucht sein, aus diesem Ergebnis auf grundsätzliche Leistungsunterschiede zwischen Uni‐ und HAW‐Studierenden zu schließen. Der Au‐ tor sieht dies aber kritisch: An der Uni war das For‐ mat der Klausurprüfung seit vielen Jahren bekannt, an der HAW war es neu; weiterhin wurden den Stu‐ dierenden an der Uni Online‐Selbsttests zur Vorbe‐ reitung auf die Klausur angeboten, die ebenfalls das gleiche Format aufwiesen; und bei einem neu beru‐ fenen Professor laufen typischerweise viele Wieder‐ holer auf, die mit den bisherigen Veranstaltern bzw. ihren Inhalten Probleme hatten und somit den Schnitt verfälschen können. Andererseits muss be‐ achtet werden, dass der Umfang von PR1 zwei Fünf‐ teln des ersten Semesters entspricht, während SE1 lediglich ein Fünftel des ersten Semesters an der Uni ausmacht.
Insgesamt gilt es also, auch diese Zahlen mit Vorsicht zu genießen.
Der Autor hat die Folge PR1 und PR2 (letzteres ist mit 3V+1P und 6 CP deutlich kleiner als PR1) in allen drei Bachelor‐Studiengängen der Informatik an der HAW durchgeführt und dabei das didaktische Kon‐ zept sowie die Inhalte beibehalten. Dabei traten überraschend deutliche Unterschiede zwischen Stu‐ dierenden der AI und TI einerseits und Studieren‐ den der WI andererseits zutage. Studien‐ gang
AI TI WI
Teil‐ nehmer 60 49 49
Schnitt 3,3 3,0 3,3 nicht be‐ standen 20% 20% 22%
Während die Klausurergebnisse sich nicht we‐ sentlich unterschieden (siehe Tabelle 1), war die Nichtbestehensquote in der Laborprüfung bei den Wirtschaftsinformatikern im Vergleich überra‐ schend hoch (siehe Tabelle 2). Studien‐ gang
Teil‐ nehmer AI TI WI 56 52 42
Schnitt 3,2 3,4 3,8 nicht be‐ standen 38% 44% 64%
Dies war umso erstaunlicher, als den Studierenden der WI‐Laborprüfung die Prüfungen der beiden vorherigen Durchgänge zur Verfügung standen, sie das Format der Prüfung (das in allen drei Prüfungen sehr ähnlich war) also besser vorhersehen konnten als ihre Kommilitonen.
Irritiert durch dieses schlechte Abschneiden, suchte der Autor nach weiteren Hinweisen, dass in der WI andere Bedingungen herrschen, und wurde in den Lehreevaluationen fündig.
Während sich diese zwischen den Studiengän‐ gen bei vielen Punkten nur unwesentlich unterschie‐ den, gab es bei der Einschätzung der Aussage Die
Unterschiede: Die AI‐Teilnehmer bewerteten dies mit einem Mittelwert von 1,76 auf der Lickert‐Skala, die TI sogar mit 1,48; die WI‐Angaben hingegen lie‐ ferten einen Mittelwert von 2,36. Auch bei allen wei‐ teren Angaben zur investierten Zeit, sowohl für die Vor‐ und Nachbereitung der Vorlesung als auch des Praktikums, lagen die Angaben bei den Wirt‐ schaftsinformatikern deutlich höher.
Offensichtlich hängt somit der Erfolg beim Pro‐ grammieren‐Lernen nicht nur von der investierten Zeit ab, sondern auch von der persönlichen Motiva‐ tion; WI‐Studierende haben häufig die Haltung, dass (eigenes) Programmieren für ihre spätere Be‐ rufspraxis eine geringere Rolle spielt; dies zeigten et‐ liche persönliche (nicht repräsentative) Gespräche, die der Autor mit Studierenden geführt hat.
Dies wurde auch deutlich in einer anonymen Er‐ hebung, die der Autor jeweils im letzten Vorle‐ sungstermin von PR1 in allen drei Studiengängen durchgeführt hat. Die letzte zu bewertende Aussage der Erhebung lautet: Dieses Modul hat meine Lust auf Informatik gesteigert. Die Studierenden konnten da‐ rauf mit Ja, Eher ja, Eher nein oder Nein antworten. Während in der AI (97% ) und der TI (100%) fast alle mit Ja oder Eher ja antworteten, waren es in der WI lediglich 75%; mehr als 20% antworteten sogar mit einem klaren Nein.
In seiner Zeit an der Uni Hamburg hat sich der Au‐ tor vergleichsweise wenig mit dem (klar ersichtli‐ chen) „Fremdeln“ der Wirtschaftsinformatiker mit dem Programmieren beschäftigt. Es schien ihm klar, dass der Erfolg beim Programmierenlernen direkt in Abhängigkeit zur investierten Zeit steht. Erst durch die intensive Erfahrung, an der HAW Hamburg ein Jahr lang ausschließlich Wirtschaftsinformatiker zu unterrichten, wurde dem Autor vor Augen geführt, dass ein entscheidendes Kriterium neben der inves‐ tierten Zeit auch die Motivation ist.
Studierende der Wirtschaftsinformatik empfin‐ den Programmieren häufig, zumindest für sich selbst, als nicht so wichtig. Dies hat einen messbaren Einfluss auf ihren Erfolg in entsprechenden Veran‐ staltungen.
Wirtschaftsinformatiker sind somit im Schnitt schlechtere Programmierer. Dies liegt nicht nur da‐ ran, dass sie insgesamt einen kleineren Informati‐ kanteil in ihrem Studium haben, sondern vermutlich auch an der mehrfach beobachteten Grundhaltung, dass sie in ihrem späteren Berufsbild eher keine ei‐ gene Programmiertätigkeit sehen. Inwieweit dies der Realität der Berufspraxis entspricht, kann hier nicht beurteilt werden. Möglicherweise sind Wirt‐ schaftsinformatiker mit einem gesunden Halbwis‐ sen der Programmierung zumindest gute Vermittler zwischen den fachlichen Anforderungen im IT‐Um‐ feld und den technischen Fähigkeiten gut ausgebil‐ deter Vollinformatiker.
Zumindest in der Informatik an der HAW Ham‐ burg wurde intern mehrfach die Frage gestellt, ob auf die hier beschriebenen Gegebenheiten mit einem speziellen Angebot für Wirtschaftsinformatiker ein‐ gegangen werden sollte. Bisher wurde dies stets ver‐ neint, mit dem Hinweis, dass alle Informatik‐Studie‐ renden die gleiche grundlegende Programmierlehre erhalten sollten. Dass die Wirtschaftsinformatiker hierbei schlechter abschneiden, wird als verkraftbar angesehen. Diese Haltung wird gestützt durch die Ergebnisse der Umfrage aus Abschnitt 2: Acht der neun WI‐Studiengänge verwenden für den Einstieg in die Programmierung die gleichen beiden Module, die auch in der Kern‐Informatik zum Einsatz kom‐ men; lediglich in einem der Studiengänge wird ein abgespecktes WI‐Paket angeboten (in dem aber le‐ diglich die Vorlesungsanteile halbiert sind).
Nach Eindruck des Autors befindet sich die einfüh‐ rende Programmierlehre in einem Spannungsfeld. Einerseits haben sich die Studierenden über die letz‐ ten Jahre stark verändert:
Sie sind aufgrund der teilweise um ein Jahr ver‐ kürzten Schulzeit und des Wegfalls von Wehr‐ bzw. Zivildienst deutlich jünger als früher; teil‐ weise sitzen 17‐jährige in den Erstsemesterver‐ anstaltungen, in denen früher kaum jemand jünger als 20 Jahre war. Eine heutige Erstsemesterkohorte setzt sich an‐ ders zusammen als früher: Vor den Zeiten des Internet‐Booms studierten vor allem die Perso‐ nen Informatik, die intrinsisch an ihren Themen interessiert waren; heute gibt es viele Studie‐ rende, die vor allem die wirtschaftlichen Vor‐ teile eines Informatik‐Studiums sehen. Diese beiden Einflüsse senken die durchschnittliche Studierfähigkeit der Studierenden.
Andererseits steigt der Anspruch an die Ergeb‐ nisse der Programmierveranstaltungen: Kollegen in höheren Semestern klagen häufig, dass die Teilneh‐ mer in ihren Veranstaltungen wie Verteilte Systeme oder Software Engineering nicht gut genug program‐ mieren können. Damit einhergehend steigt auch der Anspruch an die abgedeckten Inhalte:
Version 8 in Java hinein, entsprechend sollten auch die passenden Sprachkonzepte themati‐ siert werden. Quelltextverwaltungssysteme wie Git werden immer wichtiger, entsprechend sollte auch der Umgang mit Git früh thematisiert werden. die Java‐Bibliotheken können teilweise nur mit guten Kenntnissen von Entwurfsmustern kom‐ petent benutzt werden, entsprechend müssen Entwurfsmuster thematisiert werden. In Zeiten von Mehrkernsystemen wird neben‐ läufige Programmierung wieder wichtiger – diese war schon immer in den Genen von Java, spielt aber in den meisten einführenden Modulen nur eine geringe Rolle. Darüber hinaus stellt sich die Frage: Wo sollen Pro‐ grammierinhalte jenseits von Java diskutiert werden? Können grundlegende Sprachkonzepte, die Java nicht anbietet (z.B. andere Konzepte zur Parame‐ terübergabe, Wertsemantik bei benutzerdefinierten Typen, explizite Speicherverwaltung), überhaupt noch im Pflichtprogramm vermittelt werden? Vor allem angesichts der Tendenz, immer mehr Inhalte in der Programmierlehre in immer kleinere Anteile des Curriculums zu pressen, weil andere Inhalte des Studiums zunehmend als wichtiger empfunden werden, in letzter Zeit beispielsweise, mit zugegebe‐ ner Berechtigung, die IT‐Sicherheit?
Diese Überlegungen führen zu einer Reihe von Fragen, die bezüglich der Programmierlehre in den nächsten Jahren beantwortet werden sollten: Welchen Einfluss hat die starke Verjüngung der Studienanfänger aufgrund des Wegfalls von Wehr‐ bzw. Zivildienst und der Verkürzung der Schulzeit in vielen Bundesländern? Wie problematisch ist der Umstand, dass die Programmierlehre ihren Grundstein im ersten Semester gelegt bekommt, in dem viele Studie‐ rende häufig noch nicht studierfähig sind? Können wir es uns leisten, die Programmier‐ lehre weiter zu beschneiden? Oder sollte ihr an‐ gesichts der gestiegenen inhaltlichen Ansprü‐ che wieder mehr Gewicht gegeben werden? Wenn wir die zu Anfang dieses Abschnitts beschrie‐ benen Randbedingungen akzeptieren (müssen), dann sollten wir uns bezüglich unserer einführen‐ den Veranstaltungen weitere Fragen stellen: Welche organisatorischen Rahmenbedingun‐ gen können den Einstieg in die Programmie‐ rung erleichtern? Welche didaktischen Möglichkeiten bieten sich uns, die jungen Studierenden für das Program‐ mieren stärker zu begeistern? Welche Chancen bieten interaktive Systeme, die gerade mit Java gut vermittelt werden können, für eine interessante Programmierlehre? Welche Werkzeuge fehlen uns noch für eine bes‐ sere Programmierlehre? Sollten wir, je nach Schwerpunkt des Studien‐ gangs, eher einen Fokus auf Anwendungs‐ oder auf Systemprogrammierung legen? Wie schaffen wir es, Problemlösen mit Compu‐ tern und Sprachkonzepte zu vermitteln? Nach Ansicht des Autors gibt es hier ausreichend Klärungsbedarf für die nächsten Jahre, sowohl in der Forschung als auch in der Lehre.
Dieser Artikel beleuchtete in drei Abschnitten ver‐ schiedene Facetten der Programmierlehre. Ab‐ schnitt 2 zeigte als zentrale Ergebnisse einer Um‐ frage, dass Java‐Kenntnisse eine unumstrittene Rolle spielen und dass Lehrende von Programmierveran‐ staltungen mit ihrer eigenen Lehre überwiegend zu‐ frieden sind. Offen bleibt, ob letzteres auch für die verschiedenen „Abnehmer“ (Studierende, Lehrende höherer Semester, Arbeitgeber) gilt. Abschnitt 3 ar‐ beitete heraus, dass insbesondere Wirtschaftsinfor‐ matiker, stellvertretend für viele Bindestrich‐Infor‐ matiker, im Schnitt schlechtere Programmierer sind. Hier bleibt zu klären, ob darauf mit speziellen Lehr‐ angeboten eingegangen werden sollte. In Abschnitt 4 schließlich wurde dargestellt, dass die Program‐ mierlehre aktuell vor spezifischen Herausforderun‐ gen steht, auf die wir die richtigen Antworten noch finden müssen.
Heuer, A., et al. (2011): Entwicklung eingebetteter
Software in einem Softwarepraktikum mit Lego Mindstorms. Software Engineering im Unterricht der Hochschulen (SEUH), Hannover, dpunkt.verlag, Heidelberg. Langhoff, A., et al. (2015): Java, LEDs und ein
RaspberryPi: Ein Projektversuch mit Erstsemestern. Software Engineering im Unterricht der Hochschulen (SEUH), Dresden,
CEUR Workshop Proceedings 1332. Ludewig, J. (2010): Software‐Ingenieur werden.
Informatik Spektrum 33(3), S. 288‐291. Schmedding, D., et al. (2015): Clean Code ‐ ein neues
Ziel im Software‐Praktikum. Software Engineering im Unterricht der Hochschulen (SEUH), Dresden, CEUR Workshop Proceedings 1332. Schmolitzky, A., Züllighoven, H. (2007): Einführung in die Softwareentwicklung: Softwaretechnik trotz Objektorientierung? Software Engineering im Unterricht der Hochschulen (SEUH). Zeller,
A., Deininger, M. Stuttgart, dpunkt.verlag. Schmolitzky, A. (2013): Eine softwaretechnische
Programmierausbildung? Software Engineering im Unterricht der Hochschulen (SEUH), Aachen, CEUR Workshop Proceedings 695. Anhang A: Vollständiger Text der E-Mail-Umfrage vom März 2013 Formaler Rahmen: Wie heißt Ihre Professur/Ihr Lehrstuhl/Ihre Gruppe? Wie heißt die Hochschule, über die Sie berichten?
Wie viele Pflichtmodule zur Programmierung gibt es in diesen Studiengängen? (nicht alle müssen in allen Studiengängen Pflicht sein) In welche Studiengängen sind welche Module Pflicht? Welche Programmiersprachen werden in welchem Modul vermittelt?