Die Geschichte mit dem Hai

Die folgende Gesichte habe ich in meiner beruflichen Leben als Softwareentwickler oft erzählt. Sie ist für mich ein Beispiel für alternative Denkansätze, dem »Think outside the box«. Die Gesichte fällt leider in die Gruppe der modernen Mythen. Ob sie sich tatsächlich zugetragen hat, kann man nach der langen Zeit nur noch schwer sagen. Eine Webseite, die dem Vorfall ebenfalls thematisiert nennt ihn »The Hopefully True Story«.

In den 1960er Jahren war William (Bill) Mitchell ein führender Designer bei General Motors. Seine Interessen galten nicht nur den Fahrzeugen des Unternehmens, Mitchell war ein leidenschaftlicher Taucher und Hochseeangler. Bei einem seiner Ausflüge fing er einen Hai, den er anschließend in seinem Büro zur Schau stellte.
Nach diesem Abenteuer widmete sich Mitchell wieder seinen beruflichen Verpflichtungen und als es darum ging, das Design eines Fahrzeugs abzuschließen, wurde er seinem Fang inspiriert. Verschiedene Designelemente hatte er vor dem Tier übernommen. Außerdem verlangte Mitchell, auch bei den Farben solle der Wagen so aussehen, wie der Hai. Dabei handelte es sich im einen Farbverlauf von Dunkelblau zu Weiß. Pflichtbewusst gingen die Lackierer an die Arbeit. Als Bill Mitchell später das Tier mit dem Fahrzeug verglich, war er jedoch nicht zufrieden. Das Fahrzeug sollte den gleichen Farbverlauf haben, wie der Hai, das wäre doch nicht schwer. Die Lackierer gingen erneut ans Werk, doch der zweite Versuch scheiterte ebenfalls. Nach Meinung von Bill Mitchell war der Farbverlauf von Hai und Fahrzeug nicht identisch.

Leider ist nicht überliefert, wie viele Versuche die Lackierer unternahmen. Nach weiteren Fehlschlägen hatten sie eine Idee. Sie nahmen die Anforderungen wörtlich. Fahrzeug und Hai sollten den gleichen Farbverlauf haben. Das war machbar. In der Nacht brachen sie in das Büro von Bill Mitchell ein, stahlen den Hai und lackierten diesen! Als ihr Auftraggeber am nächsten Tag Hai und Fahrzeug verglich, waren die Farbverläufe absolut identisch. Zur Erleichterung der Lackierer war Mitchell jetzt zufrieden. Der Wagen, es handelte sich um den Marko Shark I, konnte sein Publikum ebenfalls überzeugen und ging als Chevrolet Corvette der 2. Generation in Serie. Allerdings ohne den Farbverlauf. Dieser war für eine Serienproduktion vermutlich zu teuer in der Herstellung.
Obwohl die Lackierer Bill Mitchell ein wenig betrogen haben, kann man aus dieser Gesichte eine Menge lernen. Wenn A nicht zu B passt, B aber die Anforderungen erfüllt, warum nicht A ändern?

Als Softwareentwickler sind mir solche Situationen gelegentlich begegnet. Meistens musste ich mit ansehen, wie Kollegen vor die metaphorische Wand gelaufen sind und dann ratlos dort stehen blieben. Sie wussten nicht, wie es weitergehen sollte.

Oft ging es dabei um Szenarien, bei denen eine neu entwickelte Komponente B zwar theoretisch alle Anforderungen erfüllen konnte, die Komponente A aber nicht die benötigten Daten liefert. In diesen Situationen macht sich oft Ratlosigkeit breit. Die Aussagen beginnen dann nicht selten mit: »Das können wir nicht, weil …«. Auf die Idee, Komponente A ebenfalls anzupassen kam niemand. Erst mein Hinweis, dass diese Komponente ebenfalls von uns entwickelt wurde und Änderungen kein Problem sein, schaffte Erleichterung. Selbstverständlich muss man bei solchen Änderungen darauf achten, bestehende Prozesse nicht zu stören. Trotzdem sollte man Veränderungen und Erweiterungen nicht zurückschrecken.

Bei einem anderen Fall, an den ich mich sehr gut erinnere, passten vorgegebenen Farben für ein Produktlogo nicht zu dem bestehenden Design. Auch hier wurde das aktuelle Design als unveränderlich akzeptiert und es erschienen Fragezeichen über den Köpfen. Erneut war ein kleiner Anstoß nötig, denn es gab keineswegs die Anforderung, das Logo nicht zu ändern. Letztendlich wurden sowohl Farben und Design geändert und beides zusammen ergaben für das Produkt ein ansprechendes, frisches Logo.

Manche Menschen haben die Angewohnheit, nur den Teil eines Gesamtwerkes verändern zu wollen, für den sie selbst verantwortlich sind. Die gegebenen Bedingungen zu verändern oder von anderen Personen dort Änderungen anzufordern, ziehen Sie nicht in Betracht. Obwohl das oft möglich ist.

Software-Schnittstellen können geändert werden. Ich behaupte, sie sind optimal dafür geeignet. Eine kleine Änderung im Code genügt und der Compiler verrät umgehend, wenn die Einzelteile nicht mehr zueinander passen. Das gilt es dann nachzubessern. Wenn Farben nicht zu deinem Design passen ist es an der Zeit, das Design zu überdenken. Das von vornherein auszuschließen, ist selten eine gute Herangehensweise. Und wenn es nicht anders geht, wird der Hai lackiert. Für Bill Mitchell hat es funktioniert.

Geschrieben am: 24.01.2024