Womit hat man als Trainer im Bereich Embedded-Software täglich zu tun?
Frank Listing:
Man bekommt sehr schnell mit, dass in deutschen Unternehmen des Maschinenbaus und der Automobilindustrie Software nach wie vor einen niedrigen Stellenwert hat. Die Software ist das, was am Ende dazu kommt, das funktioniert auch nebenbei, kann man ja immer noch ändern. Aber so einfach ist es leider nicht.
Wie kommt es zu dieser Entwicklung?
Der Stand der Dinge in der Softwareentwicklung hat viel mit unserer erfolgreichen Maschinenbau-Branche hierzulande zu tun. Das spiegelt sich auch in den Ausbildungsstrukturen der Entwickler wider. Programmierer im Embedded-Bereich kommen hauptsächlich aus der Elektrotechnik und dem Maschinenbau. In der Minderzahl findet man hier tatsächlich Leute, die ein bisschen mehr in Richtung Software ausgebildet worden sind. Viele lesen sich ihr Know-how an und kombinieren es mit dem, was sie vorher gelernt haben. Doch die Beherrschung der Syntax der jeweiligen Programmiersprache allein reicht nicht aus. Wenn ich Verfahren, Algorithmen und Vorgehensweisen nicht kenne, dann kann ich die auch nicht anwenden. Und sie ergeben sich auch nicht immer intuitiv. In Deutschland fehlen unterm Strich noch immer feste Ausbildungsstrukturen für Softwareprogrammierung in der Industrie. Selbst an vielen Hochschulen wird beim Programmieren ein Software-Projekt oft nicht in seinem Aufbau bewertet, sondern nur das Ergebnis. Software-Entwickler, die vorher reine Mechanik oder Elektrik entwickelt haben, sind für die Embedded-Programmierung nicht nur weniger gut ausgebildet, sie haben ja ursprünglich einen anderen Beruf gewählt und sind mitunter gar nicht besonders motiviert, gute Software zu schreiben. Nur die Wenigsten finden darin ihre neue Passion. Das Ergebnis kann man sich vorstellen.
Was kann man tun, um diese Leute für die Software-Programmierung zu begeistern?
Wenn man einmal begriffen hat, dass Software schreiben ein kreativer Prozess ist, der nicht nach einem festen Schema ablaufen muss, wenn man es richtig macht, dann kann man damit wirklich schöne Dinge entwickeln. Und wir brauchen ja heute mehr Anwendungen, die verzwickte Aufgaben lösen müssen. Das kann manche motivieren, andere wiederum nicht. Auch in der Software-Entwicklung kann man den stupiden Weg wählen, der wenig Spaß macht. Die Software funktioniert dann vielleicht auch, aber die besseren Lösungen sind meistens auch die kreativen. Bei einer Wald- und Wiesen-Ausbildung bekommt man diese Lust eben nicht vermittelt. Und dementsprechend wenig vorausschauend wird dann die Software programmiert, was sie mit der Zeit auch nicht besser macht. Das führt auch gleich zum nächsten Problem. Wenn schlecht dokumentierte Software in einem Arbeitsumfeld mit einer hohen Fluktuation entsteht, kann das katastrophale Folgen haben.
Wie würde man sich den idealen Ablauf eines Embedded-Projektes wünschen?
Erst einmal rechtzeitig über die Anforderungen nachdenken. Oft fangen Teams an zu programmieren, ohne zu wissen, was es werden soll. Und wenn ich nicht genau weiß, was am Ende des Prozesses steht, dann kann es sein, dass etwas Großes und Langsames dabei herauskommt. Bei einem gutem Embedded-Projekt steht am Anfang ein Systementwurf, also erst mal die Idee, wie die Lösung prinzipiell aussehen soll. Dafür braucht man natürlich auch schon die Requirements als Voraussetzung für den Entwurf einer Architektur. Dann wird das Ganze aufgesplittet in die Hardware und die Software, deren Entwicklung dann weitgehend parallel läuft. Der größte Fehler wird gemacht, wenn man Hardware und Software erst ganz zum Schluss wieder zusammenbringt, ohne beides vorher hin und wieder zumindest etwas zu synchronisieren und neue Anforderungen weiterzugeben. Sobald die Architektur mit ein paar Details ein bisschen verfeinert wird, kommen wir so langsam in das Programmieren rein. Softwareentwicklung ist an sich der gesamte Prozess vom Entwurf bis zum Ende der Tests. Getestet wird je nach Entwicklungsprozess entweder in der Implementierung oder kurz danach. Es kommt auch oft vor, dass man zu früh Code schreibt, ohne genügend Anforderungen zu kennen. Es fehlen noch zu viele Requirements sowie Aufbau und Architektur der Applikation, aber man legt einfach schon mal los. Das ist an sich der langsamere Weg. Als Antwort bekomme ich dann: „Es musste schnell gehen.“ Schneller geht es aber wirklich, wenn man vorher gut darüber nachdenkt, was man genau umsetzen muss.
Was sollte man vermeiden, wenn ein Projekt mal in Schieflage gerät?
Was man in diesem Moment nicht braucht, ist ein neues Tool, das einen angeblich aus der Misere herausholt. Mit einem neuen Tool kommt ein neuer Störfaktor hinzu, wenn ich es nicht vorher in Ruhe evaluiert und einstudiert habe und man es erst in das Projekt integriert, wenn man es gut kennt. Also: Programmiersprache beherrschen und eingesetzte Tools in- und auswendig kennen, sonst wird es chaotisch.
Welche Rollen im Entwicklerteam sind sinnvoll?
Im Idealfall habe ich natürlich vorher die Zuständigkeiten ausreichend definiert. Man braucht einen Softwarearchitekten, von dem auch jeder weiß, dass er diese Rolle innehat – einschließlich er selbst, versteht sich. Das können je nach Größe des Projektes auch mehrere sein. Er ist alleine oder mit einem kleinen Team für den Entwurf zuständig. Das Design verteilt sich dann bereits auf mehrere Köpfe, und die Implementierung übernimmt die ganze Mannschaft. Dieses Vorgehen gibt für das Projekt eine bereits einigermaßen vernünftige Struktur und Richtung vor.
Auf was sollte man sonst noch im Vorfeld achten?
Ein weitverbreiteter Fehler besteht darin, dass die Tester oft viel zu spät reingeholt werden. Ein Tester sollte schon bei den Requirements darauf schauen können, ob die Software und ihre Architektur überhaupt testbar sind. Wenn das nicht der Fall ist, werde ich sie auch in Zukunft nicht vernünftig weiterentwickeln können. Die Realität ist aber manchmal leider, dass erst die vermeintlich fertige Software zum Testen freigegeben wird, wodurch man unheimlich viel Zeit verliert. Wenn man die Tester stattdessen früher mit einbezieht, dann kann man bereits vorher Probleme ausschließen und frühzeitig beheben. Wenn die Tester das Problem bereits kennen, dann können sie sich schon vorher damit beschäftigen, und der ganze Zeitplan ist dadurch viel einfacher einzuhalten.
Auf den Punkt: Worin bestehen die Vorteile von Clean Code?
Clean Code steht für mich auch für eine gewisse Ästhetik. Es macht nicht nur Spaß, ihn anzuschauen, sondern er folgt auch gewissen Regeln, ist gut lesbar und enthält weniger Fehler. Mit dieser Lesbarkeit gehen auch andere Sachen mit einher: Man kann ihn einfach erweitern und muss ihn nicht verändern, um neue Dinge hinzuzufügen. Dazu braucht man nicht nur Erfahrung, sondern Freude am Programmieren überhaupt. Das Schöne dabei ist: Die Lernkurve beim Programmieren von Software ist relativ steil. Und man kann sie anheben, wenn man mal ein Lehrbuch liest oder einen Kurs besucht. Manche Fehler muss man selbst machen, andere Lösungswege kann man von anderen lernen. Und meistens macht man dann auch gleich einen großen Schritt nach vorne. In unseren Kursen sitzen zum Glück immer die Entwickler, die dazulernen wollen. Das erleichtert mir die Arbeit enorm und macht auch mehr Spaß.
