Warum Bridge Building in Engineering?

Wir müssen unsere Silos einbrechen, um in der Welt der Software-Defined Vehicles zu bestehen

Warum Bridge Builder in Engineering?

Warum "Bridge Building in Engineering"? Ich nehme tagtäglich wahr dass man die Menschen, die in der Entwicklung meiner Firma arbeiten, in zwei Kategorien einteilen kann: entweder sie sind wie Harry Hardware, oder sie sind wie Siggi Software.

Harry und Siggi leben auf unterschiedlichen Inseln

Harry und Siggi arbeiten für dieselbe Firma, sind teilweise in denselben Teams, und doch sind sie in ihren Denkmustern und ihrer Sprache oftmals komplett unterschiedlich. Sie leben gedanklich auf unterschiedlichen Inseln.

Harry und Siggi sprechen unterschiedliche Sprachen

Dass die beiden auf unterschiedlichen Inseln wohnen, macht sich am leichtesten an Ihrer Sprache fest. Wenn es z.B. darum geht, zu definieren, was ein System ist, das entwickelt wird, so beschreibt Harry das so:

"Ich entwickle mein System, definiere jeden Aspekt davon, brauche Präzision und Unabhängigkeit und gebe es frei, wenn es 100%ig korrekt ist."

wenn wir nun dieselbe Frage an Siggi stellen, dann bekommen wir folgende Antwort:

"Ich entwickle mein System, benötige ein umfassendes Verständnis der Anforderungen, strebe zumindest für die nächste Iteration Präzision an, versuche, so viel wie möglich wiederzuverwenden, und gebe es frei, wenn es einsatzbereit ist, und erwarte Rückmeldungen für die nächste Iteration"

Hier sieht man schon den grundsätzlichen Unterschied in der Herangehensweise: Harry versucht maximal unabhängig von anderen Systemen zu sein. Er hat seinen Bauraum und seine definierten Schnittstellen, das ist ausreichend. Er möchte möglichst jeden Aspekt seines Bauteils oder seiner Systemkomponente selbst in der Hand haben.

Er braucht auch die Zeit bis er etws abliefern kann, denn für ihn gibt es nur eine Deadline: sobald er etwas abgeliefert hat beginnt die Produktion des Bauteils oder des Systems. Wenn danach noch etwas geändert werden muss, dann wird das unheimlich auswendig und damit einhergehend sehr kosten- und zeitintensiv.

Siggi hat im Gegensatz dazu nicht diesen einen, sehr wichtigen Meilenstein. Natürlich muss er zum Liefertermin seine Arbeitsergebnisse abliefern, doch es besteht einen entscheidenden Unterschied: eine Korrektur und somit eine Nachlieferung ist in der Sofware um Dimensionen kostengünstiger und schneller durchzuführen als in der Hardware. Das war ja auch der Grund warum die Softwaredisziplin überhaupt entstanden ist.

Ein anderer Aspekt ist, dass Siggi versucht, so viel wie möglich wieder zu verwenden: seie es von seinem eigenen Code oder von zentralen Libraries, die entweder von anderen Fachbereichen bereitgestellt werden, oder die aus Frameworks von extern kommen. Ein wesentlicher Bereich dabei spielt Open Source Software. Diese einzusetzen ist oftmals sinnvoller als die Funktion selbst zu entwickeln.

Wenn man nun nach den Leitplanken fragt, nach den Grundprinzipien, auf denen Harry und Siggi jeweils ihren Berufsethos aufbauen, so erhält man von Harry folgende Antwort:

"Meine heilige Bibel ist die DIN-Norm (Deutsches Institut für Normung): Mach es beim ersten Mal richtig"

Siggi antwortet auf dieselbe Frage so:

"Meine heilige Bibel ist das Manifest für agile Softwareentwicklung: Oft iterieren, spät schließen"

Hier sieht man den grundlegenden Unterschied in der Herangehensweise: Harry arbeitet auf einen Zieltermin hin, danach ist er fertig. Siggi veröffentlicht zum Zieltermin einen Stand der funktioniert, entwickelt aber danach immer noch weiter und verändert und optimiert die Lösung dauerhaft. Mit entsprechenden Updatemechanismen wird somit das Produkt in Kundenhand immer weiter verbessert und optimiert.

Weiteres Zitat der beiden:

Harry: "Nach dem Packaging habe ich meinen eigenen Bauraum und kann entwickeln, bis wir unsere Komponente physisch mit anderen Komponenten integrieren."

Siggi: "Alles selbst zu machen, macht keinen Sinn. Welche Teile könnten wir auf generische Weise implementieren, so dass ich oder jemand anderes sie wiederverwenden kann?"

Man sieht an diesen Zitaten, dass es nicht nur um die verwendeten Begriffe geht, sondern es ist definitiv ein Mindset-Thema. Die Menschen wie Harry sind so konditioniert, sie haben sich diese Arbeitsmethode antrainiert und können oftmals gar nichts dafür, dass sie diese neue, aufstrebende Welt der Software nicht verstehen. Es liegt in der Natur der Sache, dass eine Änderung in der Hardware massive wirtschaftliche Konsequenzen hat, und deshalb ist jede Strategie zur Risikominimierung recht. Meist wird aber die einfachste Strategie gewählt: ich mach es lieber selbst, dann weiss ich was drin ist.

Das ist eine Herangehensweise, die Siggi Software manchmal auch hat. Nur hat diese Sache einen Haken: wenn ich etwas selbst mache statt dass ich etwas wiederverwende, dann muss ich diesen Sourcecode auch selbst pflegen. Software ist grundsätzlich sehr pflegeaufwendig. Das ist die Kehrseite der Medaille und das ist auch der Grund, warum Siggi Software immer nach generischen Lösungen sucht, die an verschiedenen Stellen wiederverwendet werden können. Ein Mittel der Wahl ist dabei die Abstraktion bzw. die Generalisierung. Und das ist auch ein wesentlicher Unterschied: diese Fähigkeit zur Abstraktion ist Harry Hardware meist nicht gegeben bzw. sie wird nicht aktiv trainiert.

Wir brauchen eine gemeinsame Sprache!

Wir brauchen eine gemeinsame Sprache. Wie wir das hinbekommen, erfahrt Ihr in den folgenden Blogbeiträgen.

Welche Erfahrungen und Beispiele habt Ihr, wo sich SW- und HW-Leute nicht verstanden haben?

Seht ihr das genauso, dass man sich erst einmal auf eine gemeinsame Sprache einigen muss, um effektiv und effizient zusammenarbeiten zu können? Hinterlasst gerne einen Kommentar oder schickt mir eine Nachricht. Stay tuned for more to come soon!

Und nicht vergessen: keep on rocking in a free world!