Wir sind kein Autowerk!

Untertitel 1: Über die Bedeutung, sich direkt in Produktionsstätten aufzuhalten, die Arbeitenden zu konsultieren und keine voreiligen Investitionen in „Optimierungen“ zu tätigen.

Untertitel 2: Warum allein die Analyse von Excel-Tabellen nicht genügt.

In jüngerer Zeit traf ich einen alten Bekannten, den ich während meines Studiums bei einem renommierten Bahnbauanlagen-Hersteller kennengelernt hatte. Er war damals mein Mentor und erzählte mir von Zeiten des Wandels in diesem Unternehmen.

Nachdem der Firmengründer in den Ruhestand trat, waren seine Nachfolger überzeugt, Modernisierungen seien nötig. Sie beauftragten teure Beratungsunternehmen, die nach langer Analyse die bisherige Produktion zweigeteilt haben. Früher wurden Lokomotiven in einer einzigen Halle hergestellt, wobei jeder Schritt reibungslos ineinandergreifend erfolgte. Doch die Consultants teilten diesen Prozess auf zwei Hallen auf, sodass nun halbfertige Lokomotiven durch das belebte Stadtzentrum transportiert werden mussten – eine logistische und finanzielle Herausforderung.

Wertvolle, erfahrene Mitarbeiter, die Bedenken äußerten, wurden entlassen. Die verbleibenden Mitarbeiter wurden zu penibler Ordnung ihrer Werkzeuge angehalten, ähnlich wie in Autowerken. Doch keine zwei Projekte waren je gleich; die starre Ordnung behinderte oft mehr, als sie half.

Nach Jahren der „Optimierung“, erheblichen Kosten und verlangsamter Produktion kehrten die Inhaber schließlich zum bewährten System zurück.

Interessant: Nach Abschluss der Umstrukturierung blieben Risse und Asphaltschäden in der Halle unangetastet – sie wurden schlicht übersehen. Ein Tag praktischer Arbeit in der Halle hätte den Beratern vermutlich mehr gezeigt als monatelange Analysen.

Die Mitarbeiterproteste: „Wir sind kein Automobilhersteller! Wir haben keine Fließbänder!“ wurden ignoriert. Daten und Diagramme auf Bildschirmen sind nützlich, doch sie ersetzen nicht die reale Erfahrung und das Fachwissen derer, die tagtäglich in der Produktion stehen.

Nachdem das teure Unterfangen von „Modernisierung“ und „Optimierung“ durch externe Berater beendet wurde und vieles wieder zum Alten zurückgekehrt war, waren die Mitarbeiter jedoch verändert. Durch den Wegfall von Gewinnbeteiligungen und anderen Bonuszahlungen waren sie nun unzufrieden.

Wenn der Code-Schreiber keine Ahnung von Compiler hat, sich aber auf ihn und seine Optimierungsalgorithmen verlässt …

Es gibt Code-Schreiberlinge, die glauben tatsächlich, dass „der Compiler eh alles optimiert„.
Andere glauben sogar, dass der Compiler eine gewisse Intelligenz besitzt.
Dann gibt es noch die Code-Schreiberlinge, die glauben, dass es gut ist, wenn sie jede Methode mit einem Try-Catch-Block zu versehen. Nachdem Motto „Bringt nichts, schadet nichts“ und/oder „Doppelt hält besser„.


Schauen wir uns das ganze Mal genauer an.
Wieder mal ein Stück Code aus freie Wildbahn (Industrie):

// Listing 1 (ugly code)

void Main()
{
	Console.WriteLine(GetSomething(0));
}

public double GetSomething(int value)
{
    try
    {
        return 0;
    }
    catch(Exception ex)
    {
        return 0;
    }
}

Man stelle sich nun vor (das wird mir niemand glauben) es gäbe ein SW-System mit hundert und mehr solche Methoden wie „GetSomething(int)„.

Der folgende Code tut exakt das Gleiche, nur viel CPU und Speicher freundlicher, überschaubarer, verständlicher und einfacher zu lesen:

// Listing 2 (better code)

public const double DBL_CONST = 0.0;

void Main()
{
	Console.WriteLine(0);
}

Und nun schauen wir uns mal an, was der Compiler:

  • Optimiert, und es dann
  • in „Intermediate Language“ (IL) Befehle für CLR übersetzt, und anschließen für den echten CPU (Hardware)
  • ins Assembler übersetzt

Fangen wir mal mit Listing 1 (ugly code) an:

Von links nach rechts: C# optimiert, IL, ASM (intel x64)

Man stelle sich vor der Code oben wird in einer Schleife immer wieder aufgerufen …

Und nun schauen wir uns Listing 2 (better code) an:

Von links nach rechts: C# optimiert, IL, ASM (intel x64)

Wie man sieht, wird der CPU bei Listing 1 (ugly code) unnötig beschäftigt. Man könnte meinen, es handle sich um eine „Beschäftigungstherapie“ für den CPU: „Das es eahm jo ned langweilig wird!„.

Wegen solche Code-Schreiberlinge, benötigen wir immer stärkere CPUs, noch mehr Cores pro Sockel, und immer mehr RAM. Von der Energieverschwendung und dem CO₂ Bilanz ganz zu schweigen.

Englisch, Deutsch oder Denglisch?

Der Kunde zahlt fürs Code-Schreiben und nicht fürs Code-Lesen!

In einer Firma, wo alle Software-Entwickler und IT’ler Deutschsprachige waren, hat der Inhaber & CEO uns befohlen alle Kommentare (nur Kommentare) auf Deutsch zu schreiben. Ein Jahr später, nachdem das Projekt im Verzug war und die Entwicklung des Software-Systems nicht schnell genug vorangegangen war, wurden drei neue Software-Entwickler aus Spanien eingestellt. Die neuen Kollegen waren alle sehr gute Software-Entwickler und beherrschten souverän ihr Fach, jedoch verstanden kein Wort Deutsch. Danach wurden noch mindestens fünf weitere Software-Entwickler, ebenfalls aus Spanien, eingestellt…
Nun hatten wir alle Hände voll zu tun. Wir drei Deutschsprachigen müssten alle Kommentare nun auf Englisch übersetzen und ersetzen, anstatt unsere Aufgaben nachzugehen.

In eine andere Firma, hatte ich das „Vergnügen“ Code auf Denglisch zu lesen. Manche Namen waren Deutsch, manche waren Englisch, und der Rest eine beliebige Mischung aus Deutsch und Englisch. Dass alle Programm-Elemente (Interfaces, Klassen, Delegates, Events, Methoden, Properties etc.) in Microsoft .NET Frameworks auf US-Englisch waren, ist natürlich trivial…

Das Lesen der Code war extrem schwierig und eine Herausforderung an/für sich. Beispiel für Variable-Namen:
messValue, measWert, measValue, messWert (diese Namen standen für: measured value, bzw. gemessener Wert).
Auch wenn man alle Namen auf Deutsch schreibt, die Hälfte von Code ist und bleibt auf Englisch, da die Schlüsselwörter und alles Andere in MS .NET Frameworks in US-Englisch ist, wie: string.IsNullOrEmpty(…), PropertyChanged, File.Exist(…), using(var x = new MemoryStream(…)), usw. usf.

Deswegen behaupte ich: Es kann kein Code auf „Deutsch“ geschrieben werden, wenn man das versucht, dann entsteht immer ein Code auf „Denglisch“. Man stelle sich nur vor, jemand würde Denglisch schreiben oder reden:
„I war very froh to sehen you nochmal“.

Ich verwende gerne US englische Namen (Color statt Colour, Synchronize statt Synchronise, usw.). Somit bleibt alles einheitlich, unmissverständlich, eindeutig, klar und der Lese-Fluss bleibt sehr flüssig.

Denglisch kostet mehr Zeit, mehr Zeit zum Lesen und mehr Zeit zum Verstehen.
Je öfter der Code von je mehr Kollegen (wieder)gelesen wird, desto mehr Zeit wird verschwendet!
Zeit ist Geld. Somit verursacht Code auf Denglisch unnötige zusätzliche Kosten.

Der Kunde zahlt fürs Code-Schreiben und nicht fürs Code-Lesen!