«Die Software ist fast fertig, wir müssen sie nur noch auf dem Gerät integrieren.» Diese Aussage ist eine der grössten Selbsttäuschungen in der Entwicklung von Embedded Software. Die Folgen davon sind verheerend: Über Wochen und Monate werden jede Menge «Abkürzungen» und Tricks ausprobiert, um die Auslieferung des Geräts doch noch irgendwie einzuhalten – zumindest so gut wie möglich. Anschliessend erfolgt die Ernüchterung: Das Produkt, dem eigentlich eine grosse Zukunft beschieden war, bleibt häufig hinter den Qualitätsansprüchen der Entwickler sowie der Auftragssteller zurück.
Doch wie kann solchen Problemen aus dem Weg gegangen werden? Die Lösung: eine frühzeitige und häufige vertikale Integration. Sie ist nicht nur der Weg aus der Sackgasse, sondern oftmals auch ein Game-Changer auf dem Weg zu besseren Produkten und mehr Agilität.
Integration als kniffligster Teil der Produktentwicklung
Entwickler, die sich mit Embedded Software befassen, wissen meistens ganz genau, dass die Integration der kniffligste Part der Produktentwicklung ist. Denn oftmals entwickeln Unternehmen die Komponenten eines Embedded-Geräts – Betriebssystem, Hardware und Anwendungen – parallel, aber isoliert. Handovers finden nur gelegentlich statt und die Integration folgt erst, wenn alles erledigt ist. Das kann sicherlich funktionieren. Ich habe aber in meiner jahrelangen Berufserfahrung nie erlebt, dass auf diese Weise der Zeitplan eingehalten wurde und keine schmerzhaften Einschnitte bei der Produktqualität gemacht werden mussten.
Eine frühzeitige und regelmässige Integration ist daher ein Muss, um die Qualität zu gewährleisten und das Terminziel einzuhalten. Wenn Entwickler nicht sehen, wie ihr Programm in der Realität – oder unter annähernd realen Bedingungen – läuft, müssen sie von Annahmen ausgehen. Doch diese Annahmen sind die Ursache vieler Softwarefehler und undefiniertem Verhalten. Das Rezept dagegen liegt auf der Hand: Die regelmässige (Test-)Integration des gesamten Produkts. Sie zeigt Schwächen im System, die anders nicht erkannt worden wären.
Ein weiterer Nebeneffekt der Testintegration: Das Team kommt in Sachen Integration nicht aus der Übung. Um dies zu leisten, wird das Deployment meist automatisiert und dadurch zu einer Trivialität im Entwicklungsprozess. Der Lohn: mehr Systemstabilität in der Produktion.
Elon Musk macht’s vor
Ein sehr prominentes Beispiel für häufige und frühe Integration sind die Raketen von SpaceX. Sie erinnern sich vielleicht an all die YouTube-Videos von Elon Musks abstürzenden Raketen? Hier findet vertikale Integrationen im ganz grossen Rahmen statt. Ich bin vollkommen überzeugt, dass alle Teile der frühen Falcon 9 im Labor und unter Prüfbedingungen bestens funktioniert haben. Und doch waren die ersten Starts der vollständig zusammengebauten Rakete wiederholt von unerwarteten und spektakulären Pannen begleitet. Das Geld, das mit jeder dieser Raketen in die Luft gegangen ist, liegt nicht unbedingt im Budget jedes Unternehmens. Doch es zeigt die Wichtigkeit der vertikalen Integration, auch wenn man dazu nicht jedes Mal sein Produkt in die Luft gehen lassen muss.
Häufige vertikale Integration ist ein exzellenter Türöffner, wenn es darum geht, das Potenzial einer interdisziplinären Gruppe von Ingenieuren auszuschöpfen. Diese müssen kooperieren, um eine vereinfachte und automatisierte Integration und Implementierung zu entwickeln und um versteckte Annahmen aufdecken.
Vertikale Integration ist eine Seite der Medaille, Messen und Überwachen die andere. Jedes Mal, wenn ein System in der Entwicklungsphase implementiert und einer sinnvollen Testreihe unterzogen wird, erhalten alle Beteiligten wertvolles Feedback. Wann immer Ruhe einkehrt, etwa am Wochenende, dann lassen Sie doch ein paar anspruchsvolle Tests auf der neusten Version des Systems laufen. Denn für Entwickler gibt es am Montagmorgen keinen besseren Muntermacher als ein fehlgeschlagener Integrationstest.
Die Kosten für den Aufbau amortisieren sich schnell
Natürlich sind die Kosten für den Aufbau einer Umgebung zur vertikalen Integration nicht von der Hand zu weisen. Neben den Kosten für Hardware und Testsysteme ist auch die Zeit ein wichtiger Faktor, die in den Aufbau einer Umgebung zum Testen und Überwachen der Produkte investiert werden muss. Doch amortisiert sich dieser Aufwand später ohne Weiteres, denn häufig verkürzt sich der Zeitaufwand für die Reproduktion von Bugs und die Erstellung von Patches dadurch signifikant. Zudem kann die Infrastruktur oft auch für die Bereitstellung von produzierter Software in der Produktion genutzt werden.
Ich empfehle nach Möglichkeit eine Hardwareausrüstung pro Entwickler bereitzustellen – so können Tests unabhängig von den anderen Teammitgliedern erfolgen. Zudem entstehen weniger Wartezeiten bis Testressourcen verfügbar sind. Ein kritischer Programmierfehler, der in einem späten Entwicklungsstadium gefunden wird, kann weitaus mehr kosten als die Anschaffung bzw. der Aufbau zusätzlicher Hardware.
Risiken bei «Over the air updates» ausschalten
Heutzutage müssen Updates in immer kürzeren Abständen eingespielt werden, auch wenn die Software sich bereits in einer produktiven Umgebung befindet. «Over the air updates» werden auch im Embedded-Umfeld zum Standardfeature. Die Risiken sollten aber nicht unterschätzt werden, denn ein fehlgeschlagenes Update kann ein Gerät zum Absturz bringen und den Geschäftsbetrieb empfindlich stören oder sogar Menschen gefährden. Mit vertikaler Integration wird jedes Mal getestet, wenn sich der Code ändert. Das erhöht die Chance, mögliche Fehler in einer unkritischen Umgebung zu erkennen. Wenn man die Kosten bedenkt, die entstehen, wenn ganze Fabriken wegen eines fehlgeschlagenen Updates tagelang stillstehen, relativiert sich der zusätzliche Aufwand für eine kontinuierliche vertikale Integration deutlich.
Fazit
Eine frühe und häufige vertikale Integration mag zwar hohe Initialkosten haben, bringt aber mittel- und langfristig deutliche Vorteile mit sich. Wenn man bedenkt, dass eingebettete Geräte in der Regel über Jahre und Jahrzehnte gewartet und verbessert werden, zahlt sich die Investition in der Regel aus. Die Frage, ob kurzfristige Gewinne mehr zählen als die Schnelligkeit und der Qualitätsgewinn in der Entwicklung, stellt sich erst mit der Zeit.
Dieser Artikel erschien bereits auf Englisch im persönlichen Blog von Dominik Berner.
Der Autor
Dominik Berner
Dominik Berner war Senior Software-Ingenieur bei bbv. Dank seines Know-hows im MedTech-Bereich kennt er die Wachstumsgrenzen von Start-ups und Kleinunternehmen, aber auch die Verhältnisse in Grossfirmen. Als Agilist betrachtet Berner Softwareentwicklung als Teamsport, der eine starke Unternehmenskultur erfordert.