Warum eure Software mehr Personal frisst als Weihnachtskekse 🍪💻

Oder: Was Omas, Stanzmaschinen und LEGO euch über Software-Entwicklung beibringen können

Es gibt Firmen, die seit Jahrzehnten die gleichen Produkte, Maschinen oder Anlagen herstellen – und dafür Software benötigen. Seit Jahrzehnten beschäftigen sie Software-Entwickler. Und jedes Jahr brauchen sie mehr davon: mehr Entwickler, mehr Architekten, mehr Projektleiter. Die Kosten steigen, die Teams wachsen.

Und doch fragt sich niemand:
👉 „Warum ist das so?“
👉 „Warum geben wir jedes Jahr mehr für Software aus?“

Vielleicht helfen ein paar Vergleiche …


Die Wirtschaftlichkeit hausgemachter Weihnachtskekse 🎄🍪

Stell dir Oma beim Keksebacken vor:

  • Holt sie jedes Jahr neue Keksformen? Nein.
  • Braucht sie immer mehr Ausstecher, um dieselben Vanillekipferl zu machen? Natürlich nicht.

Die Formen halten jahrelang – und die Rezepte sowieso.


Die Wirtschaftlichkeit der Stanzmaschinen 🏭🔩

Es gibt Firmen, die Blech stanzen. Sie kaufen sich einmal Stanzmaschinen, die jahrzehntelang laufen.
Nur die Formen (die Werkzeuge) werden ab und zu getauscht – je nach Auftrag oder Abnutzung.

Keiner käme auf die Idee, die ganze Maschine jedes Jahr wegzuschmeißen.


LEGO® und die Kunst der Wiederverwendung 🧱✨

LEGO® bringt ständig neue Sets heraus – Raumschiffe, Schlösser, Dinosaurier, super geile Kampfroboter mit Laser, Phaser und Chat GPT 😉. Aber die meisten Steine sind seit Jahrzehnten gleich: Noppen oben, Löcher unten.

Die Maschinen, die die Steine spritzen, laufen jahrzehntelang. Sie werden nur ersetzt, wenn Automatisierung, Energieeffizienz oder Industrie-4.0-Spielereien echte Vorteile bringen.


Fazit 🤔

Liebe Firmen,
wenn ihr seit Jahrzehnten Software entwickelt und trotzdem jedes Jahr mehr Entwickler braucht, dann stellt euch bitte mal die Frage: Warum?

Vielleicht liegt’s daran, dass eure Software gar nicht so soft ist.
Vielleicht ist sie eher wie Hardware: starr, schwerfällig und unflexibel.

Und wenn das so ist … dann wundert euch bitte nicht, dass die Personalkosten explodieren. 😉

Wenn Software-Updates mehr kaputt machen als sie reparieren: Ein persönlicher Erfahrungsbericht mit GIMP 3.0.4

Mit GIMP 3.0.4 wurde aus einem stabilen Werkzeug ein Bug-Monster: blockierte Shortcuts, verwaiste Dialoge, kaputte Export- und Font-Funktionen. Der Release wirkt wie KI-generierter Code ohne echte Tests – ein Beispiel dafür, dass KI, CI/CD und Automatisierung keine menschliche Qualitätskontrolle ersetzen können.

Vor wenigen Minuten habe ich über 1 Stunde 30 Minuten damit verloren, der GIMP-Community auf GitLab mehrere Bugs zu melden. Normalerweise mache ich das gerne, wenn ich auf Fehler stoße – schließlich lebt Open-Source-Software davon, dass Nutzer:innen Rückmeldung geben. Aber diesmal war es anders: Die Anzahl, Art und Systematik der Bugs in GIMP 3.0.4 geben mir ein sehr ungutes Gefühl.

Vor dem Update lief alles perfekt

Mit der Version vor 3.0.4 war ich rundum zufrieden. Alles funktionierte reibungslos, die Bedienung war konsistent, und es gab keine Stolperfallen im Workflow. Eigentlich hätte es kein Update gebraucht. Doch aufgrund des Splashscreens mit der neuen Versionsbenachrichtigung habe ich das Update trotzdem eingespielt – und plötzlich ging nichts mehr wie zuvor.

Ein Update voller Stolperfallen

Die Liste der Fehler ist lang, hier nur ein Auszug:

  • GIMP hat plötzlich einen globalen Keyboard Hook, der selbst außerhalb von GIMP alle Shortcuts wie Ctrl+C, Ctrl+V oder Ctrl+S blockiert (VS Code, VS 2022, Android Studio, Linqpad, Notepad++ usw.)
  • Mehrere Dialogfenster verlieren ihren Kontext und werden zu „verwaisten“ Fenstern, die sich unkontrolliert vervielfachen.
  • Im Export-Dialog wächst Text nicht nach rechts, sondern nach links aus dem Fenster hinaus – und die restliche UI reagiert nicht mehr.
  • Die Font-Auswahl und Größenänderung verhält sich grotesk: Statt den Wert im Feld zu ändern, landet meine Eingabe im eigentlichen Bildtext. (Mein Verdacht: die Beschreibung für Code-generierender KI war nicht eindeutig und missverständlich und dadurch hat der KI die Textfelder von Font-Eigenschaften mit dem Text im Bild (Layer) verwechselt. Das passiert oft und ist typisch für Coder mit sehr wenig Erfahrung in Coding und Software-Engineering)
  • Nach dem Rotieren oder Einfärben von Ebenen entstehen nach dem Zuschneiden plötzlich verschobene Layer-Kopien.

Das sind keine Kleinigkeiten, sondern fundamentale Fehler, die das Arbeiten massiv behindern.

Mein Verdacht: KI-Code ohne echte Tests

Die Häufung und Art dieser Bugs weckt bei mir einen starken Verdacht:

  • Es wirkt, als wären viele Code-Änderungen automatisiert entstanden, möglicherweise mit Hilfe von KI-generiertem Code. Z.B. durch unzureichende, nicht-eindeutige und missverständliche Beschreibung für KI, wurde ein Code generiert der zwar mit kein(e) einzige(r) Compiler-Fehler/Warnung übersetzt werden (und laufen) kann, aber sich bei der Nutzung völlig falsch verhält.
  • Darauf aufbauend hat man sich blind auf CI/CD-Pipelines verlassen, ohne dass echte Menschen die Software in Alltagsszenarien getestet haben.
  • Das Ergebnis: ein Release, das wie ein Krebs-Geschwür über die Community ausgerollt wurde.

Natürlich ist das nur mein Eindruck als Nutzer (mit 17+ Jahren Erfahrung in Software-Engineering und Entwicklung). Aber die Systematik der Fehler lässt kaum an Einzelfälle glauben.

KI ersetzt weder Menschen noch Tests durch Menschen

Ich möchte hier einen Punkt betonen: KI kann helfen, Code schneller zu schreiben oder Vorschläge zu liefern. Aber ohne menschliche Qualitätskontrolle, manuelles Testen und kritisches Hinterfragen wird jede Software zur Zumutung. Continuous Delivery (CD) und Continuous Integration (CI) sind mächtige Werkzeuge – aber sie ersetzen nicht das Verständnis für Usability und händisches Durchklicken, das echte Fehler sichtbar macht.

Fazit

Software-Updates sollten Verbesserungen bringen, nicht Regressionen. Im Fall von GIMP 3.0.4 war das Gegenteil der Fall. Ich musste auf die vorherige Version zurückrollen, weil grundlegende Dinge nicht mehr funktionierten.

Mein Appell an alle Entwickler:innen (egal ob Open Source oder kommerziell):

  • Nutzt KI, aber lasst sie nicht allein entscheiden.
  • Vertraut auf CI/CD, aber ergänzt sie mit echten Tests durch Menschen.
  • Denkt an eure Nutzer:innen – sie verlieren sonst Stunden ihrer Lebenszeit für Dinge, die gar nicht hätten passieren dürfen.

Die Update-Mafia und ihr Update-Perpetuum-Mobile – eine Massenvernichtungswaffe im Dauerbetrieb

Es hat sich wohl inzwischen als „neue Normalität“ eingebürgert: Mircosaft wirft für sein geliebtes Windoof „Updates“ in einer Frequenz ab, die selbst einen B52-Bomber vor Neid erblassen lässt. Und wie bei Teppichbombardements üblich, wird dabei selten gezielt – Hauptsache: viel hilft viel.

Millionen Computer in Büros, Werkhallen und Industrieanlagen werden reihenweise lahmgelegt, aus dem Takt gebracht oder komplett unbrauchbar gemacht. Die Folge: Millionen Arbeitsstunden werden kollektiv im Modus „Trial-and-Error“, „Hoffen und Bangen“ oder schlicht „Däumchendrehen“ verbrannt. Produktivität? Fehlanzeige.

Die Code-Schreiberlinge aus dem Hause Mircosaft in Redmond scheinen ihren bewährten Google-Copy-and-Paste-Workflow längst zugunsten eines neuen Verfahrens ersetzt zu haben: Ask-ChatGPT-and-Paste. Anders lässt sich kaum erklären, warum auf ein Update (KB5058499), das angeblich „Fehlerbehebungen“ und „Verbesserungen“ bringen sollte, ein Update (KB5060842) folgt, das die Fehler des vorherigen Updates beseitigen will – nur damit daraufhin (tusch!) das Update KB5063060 erscheint, um… genau: die neuen Fehler zu beheben. Ein Update-Wirrwarr in Endlosschleife (dazu mehr hier sowie hier oder hier von einem anderen tapferen Kameraden)

Man möchte es kaum glauben, aber es ist die perfekte Beschreibung meiner patentierten „Never Ending Baustelle“® (Copyright ©2007-2025 by Pedram GANJEH-HADIDI). Eine Dauerbaustelle, vor der ich schon vor über einem Jahrzehnt meine Kollegen gewarnt und Freunde sowie Ex-Studienkollegen regelmäßig in Schutz genommen habe.

Die Ursache?
Ganz einfach: „Typing first, Bedenken second!“ – frei nach dem FDP-Slogan „Digital first, Bedenken second“ von Christian Lindner. Oder, um es in meiner Sprache zu sagen: Erst in die Tasten hauen, dann (vielleicht) drüber nachdenken.

Programmieren als Beschäftigungstherapie – und der tiefere Sinn (oder Unsinn?) von Code

Früher kaufte man Computer und Software, um echte Probleme zu lösen – schnell, präzise, effizient. Heute hingegen bekommt man Software, die selbst das Problem ist – und Updates, die das Problem im Wochenrhythmus neu erfinden.

Wer seine Lebenszeit sinnlos vergeuden oder sich ärgern möchte, braucht dafür weder Videospiele noch Reality-TV – ein Windoof-Update genügt!

Man stelle sich vor: Man geht zum Arzt, zahlt für Medikamente – und bekommt dafür Kopfschmerzen. Oder man bringt sein Auto in die Werkstatt, zahlt für eine „Wartung“ – und es springt danach nicht mehr an.

Und bei Mircosaft? Genau das ist Konzept. Willkommen im Zeitalter der „Bugfix-Fabriken“, in dem Stabilität zur Legacy geworden ist und „Release Notes“ wie Apokalypse-Kalender gelesen werden.

Es ist kein Wunder, dass ich inzwischen unter Updateophobie leide und KB5063060 Links liegen lasse, wie inzwischen viele Andere auch.

Es entsteht zunehmend der Eindruck, dass heutzutage nahezu jeder – unabhängig von Qualifikation oder Verantwortungsbewusstsein – Software entwickeln und auf den Markt bringen kann, ohne je für etwaige Folgen wie Funktionsstörungen, Zeitverlust oder mentale Belastungen zur Verantwortung gezogen zu werden.

Ebenso könnte man meinen, dass viele Schlüsselpositionen in Behörden, Normungsgremien und europäischen Institutionen nicht immer nach Kompetenz, sondern eher nach politischer Zweckmäßigkeit oder Karrierelogik besetzt werden. Anders lässt sich das anhaltende Versagen bei der Regulierung und Qualitätssicherung kaum erklären – zumindest nicht aus Sicht betroffener Anwender.

Klaus und seine magische Kiste: Warum Monolithen nicht die Antwort sind

Neulich erzählte mir mein Beifahrer von einem faszinierenden Geschäftspartner in der Mechatronik und Automatisierung. Dieser war seit Jahren in der Branche tätig und frustriert über die ständigen Anpassungen in komplexen Systemen. Jede kleine Änderung führte dazu, dass Kollegen monatelang das gesamte System umstellen mussten. Ein neuer SPS-Typ, der keinen GOTO-Befehl unterstützte? Problem. Ein spezieller Sensor, der nur RS-232, aber kein CAN konnte? Noch ein Problem. Also beschloss unser Held, das Problem ein für alle Mal zu lösen, indem er eine programmierbare „magische Kiste“ baute – ein Gerät mit allen möglichen Schnittstellen, das angeblich jedes Kompatibilitätsproblem beheben sollte. Ohne Code. Klingt toll, oder? Nun ja…

Als ich diese Geschichte hörte, musste ich schmunzeln. Ich unterbrach meinen Beifahrer und erklärte ihm, warum ich skeptisch war – anhand der berüchtigten All-in-One-Stereoanlagen aus den 1980er Jahren. Diese Geräte waren damals der letzte Schrei und versprachen alles in einem: CD-Player, Kassettendeck, Verstärker, Radio – und oft sogar einen Schallplattenspieler. Doch sie waren Monolithen, und das brachte erhebliche Nachteile mit sich:

  1. Monolithen und Modularität: Wenn das eingebaute Netzteil oder der Verstärker kaputtging, funktionierte gar nichts mehr. Weder der CD-Player noch die Kassettendecks – alles war tot.
  2. Bezahlte Überflüssigkeit: Selbst wenn man nur CDs abspielen wollte, zahlte man für Funktionen, die man nicht brauchte – wie ein zweites Kassettendeck oder den eingebauten Plattenspieler.
  3. Platzfresser: Diese Geräte waren riesig und belegten mehr Raum als nötig.
  4. Eingeschränkte Kompatibilität: Lautsprecher konnten manchmal ersetzt werden, aber nur, wenn sie über standardisierte Cinch-Buchsen angeschlossen waren. Wenn nicht, Pech gehabt.
  5. Qualitätskompromisse: Audiophile legten sich oft zwei Systeme zu, weil eines bessere Kassettenwiedergabe bot, während das andere bei CDs brillierte.

Und das alles in einer Ära ohne EU-Gewährleistung! Manche Hersteller boten stolz ein halbes Jahr Garantie, andere gerade mal zwei Monate.

Die Wende zur Modularität

Ende der 80er und Anfang der 90er lernten die Hersteller aus ihren Fehlern. Sie zerlegten ihre Monolithen in einzelne Module. Verbraucher konnten nun:

  1. Nur die Module kaufen, die sie tatsächlich benötigten.
  2. Komponenten verschiedener Hersteller kombinieren: ein Kassettendeck von Marke X, ein CD-Player von Marke Y und ein Verstärker von Marke Z – ideal, um die 1000-Gigawatt-Boxen fürs nächste Erdbeben mit Saft zu versorgen.

Die Lektion für die Software

Die Geschichte der Stereoanlagen zeigt, warum Modularität wichtig ist – eine Lektion, die auch in der Softwareentwicklung gilt. Die Frustration des Automatisierungs-Mechatronikers, der nach jeder kleinen Änderung das gesamte System anpassen musste, deutet auf ein grundlegendes Problem hin: Ad-hoc-Programmierung ohne durchdachte Software-System-Architektur.

Ein erfahrener Softwareentwickler (bzw. SW-Architekt) hätte sich sofort gefragt:

  1. Was, wenn Hersteller U nicht mehr existiert?
  2. Was, wenn Hersteller V das Produkt nicht mehr anbietet?
  3. Was, wenn Hersteller W die Lizenzbedingungen ändert?
  4. Was, wenn Hersteller X seine Treiber oder Schnittstellen ändert?
  5. Was, wenn Hersteller Y nur noch neue Modelle ohne vollständige Abwärtskompatibilität verkauft?
  6. Was, wenn Standard Z obsolet wird?

Die Liste ließe sich endlos fortsetzen. Ohne diese „Was-wäre-wenn„-Fragen läuft man Gefahr, eine digitale eierlegende Wollmilchsau zu bauen – eine magische Kiste, die zwar beeindruckend klingt, in der Praxis aber niemand will.

Niemand möchte von einem einzigen Hersteller abhängig sein, oder von einem einzigen Softwaresystem oder Produktmodell usw.

Niemand möchte mehr für Schnittstellen und wunderbare Features und Möglichkeiten bezahlen, die zwar mehr Raum und Speicher belegen und komplexer sind, diese aber nicht benötigt.

Der Unterschied zwischen Coder und Architekt

Hier kommt die entscheidende Lektion: Code zu schreiben ist nicht dasselbe wie Softwarearchitektur. Wer die Konzepte von Modularität, Komplexität und Abhängigkeiten nicht versteht, investiert vielleicht Jahre in einen Monolithen, der letztlich unbrauchbar ist.

Also, wenn Ihnen das nächste Mal jemand eine magische All-in-One-Lösung verspricht, denken Sie an die Stereoanlagen der 80er – und seien Sie skeptisch. Modularität mag weniger glamourös klingen, aber sie ist der Schlüssel zu langlebigen, flexiblen und wartbaren Systemen. Und das gilt für Hardware genauso wie für Software.

Gewidmet an P.M. (der Beifahrer)
Im nächsten Artikel erkläre ich dir, wie manche mit Buzz-Words wie „Low Code“ und „No Code“ viel Geld für das Blaue vom Himmel und sonstige Versprechungen (Blabla) verlangen und reich werden, während ihre Kunden doppelt und dreifach draufzahlen.

Ewige Jugend bedingt junges Blut – Mit der Jungblut-Spritze gegen das Jurassic-Park-Syndrom

Ältere Mitarbeiter, die die gesamte Geschichte unserer Produkte von Anfang an nicht nur miterlebt, sondern mitgestaltet haben, sind von unschätzbarem Wert für die Unternehmens- und Produktkultur sowie für die Bewahrung von Wissen und Erfahrung. Ihr Fehlen könnte Lücken hinterlassen, die hohe Kosten verursachen.

Um technologisch auf dem neuesten Stand zu bleiben und moderne Konzepte, Paradigmen und Innovationen nicht zu verpassen, ist es unabdingbar, regelmäßig neue junge Mitarbeiter einzustellen, insbesondere im Bereich der Informationstechnologie. Ein Paradebeispiel hierfür ist die dynamische Interaktion zwischen der Smartphone-Generation, die der Wählscheibentelefon-Generation bei der Nutzung von Apps und der Navigation durch Einstellungen hilft.

Im Jahr 2009 musste der neue CEO eines Unternehmens, für das ich damals tätig war, den Kunden erklären, warum die Spiele in 16-Bit-C geschrieben wurden und warum nach 8 Jahren Windows XP immer noch MS-DOS 7 als Betriebssystem erforderlich war. Obwohl das Unternehmen über mehr als 30 Softwareentwickler verfügte, begann es erst 2010, ein Versionsverwaltungssystem (Subversion) einzuführen. Zusätzlich wurde die Unternehmensstrategie hinsichtlich des Schutzes vor Code-Diebstahl und Reverse-Engineering nach 15 Jahren von einem absoluten Verbot von Code-Kommentaren („Security by Obscurity“) zu einer Kommentarpflicht für jede Funktion und jede Code-Datei umgestellt.

Diese Modernisierungen kamen jedoch zu spät, da bereits seit Jahren 13 externe Softwarehäuser Spiele für meinen damaligen Arbeitgeber programmiert hatten. Dies lag daran, dass das Unternehmen den Anforderungen und Bestellungen nicht gewachsen war, was zu enormen Kosten durch externe Dienstleister führte. Interessanterweise begann ich meine Tätigkeit dort im Jahr 2007, und obwohl ich bereits 2002 an der JKU Linz das Konzept des Unit-Testings gelernt hatte, hatte das Unternehmen nie davon Gebrauch gemacht, obwohl einige wenige Softwareprojekte teilweise in C++ und nach objektorientierten Prinzipien entwickelt wurden.

In solchen Situationen drückt das persische Sprichwort „نوشدارو بعد از مرگه سهراب“ („Medikation erst nach Sohrabs Tod“) treffend aus, dass manchmal die Rettung zu spät kommt.

Die scheinbaren Kosteneinsparungen, die entweder für ein einzelnes Produkt oder aufgrund vorübergehender wirtschaftlicher Schwierigkeiten getroffen werden, potenzieren sich nicht nur miteinander, sondern auch im Laufe der Zeit und erweisen sich stets als Bumerang. Wer Zweifel hegt, braucht sich nur die Geschichte von Unternehmen wie Kodak anzusehen, oder den aktuellen Fall von Boeing 737 Max zu betrachten, oder einfach zu recherchieren, welche Stundensätze für Fortran-, Cobol- oder Algol-Programmierer üblich sind (Ja! Es gibt tatsächlich Ämter wie IRS – das US-Finanzamt – und Firmen die immer noch Teilweise von solche Keilschrift-Programmiersprachen abhängig sind).

Fun Fact 1: Ein Mitarbeiter von Kodak hatte bereits im Jahr 1972 eine voll funktionsfähige Digitalkamera entwickelt und patentiert. Jedoch verweigerten die Manager von Kodak jegliche Anerkennung und untersagten dem Erfinder sogar, darüber zu sprechen. In den 1990er Jahren wurden sie schließlich von der Konkurrenz überholt, sodass ihre einst führende Marke in der Fotografie weniger als 1$ wert war. Die NASDAQ erwog sogar, sie aufgrund ihrer geringen Börsenbewertung aus dem Handel zu entfernen, was einem sogenannten „Penny Stock“ gleichkam.

Fun Fact 2: Boeing hat aufgrund des Konkurrenzdrucks durch Airbus immer wieder entschieden, die 737 lediglich anzupassen, anstatt sie von Grund auf zu erneuern. Doch wie man weiß, kann man mit alten Steinen kein neues Haus bauen – eine Erkenntnis, die sie spätestens kürzlich einholte. Der Ruf des Unternehmens ist beschädigt, die Marke ruiniert und das Vertrauen von Fluggesellschaften, Versicherungen und Passagieren ist dahin.

Die Ära des Elektroflops: Wenn Technologie ihre Versprechen nicht einlöst

Ich war zutiefst erstaunt, als mein sehbehinderter Vater mir sein neues Smartphone vorführte und seinen Unmut darüber äußerte.

Anfangs hegte ich Zweifel, doch dann nahm ich das eigens für Blinde entwickelte Smartphone mit physischer Tastatur und Google Assistant-Taste in die Hand und testete es selbst.

Szenario 1: Notfall
Stellen Sie sich vor, ich fahre meinen Vater im Winter bei Minustemperaturen, und wir erleiden einen Unfall. Das Auto liegt auf dem Dach, die Batteriesäure tritt aus, es brennt im Motorraum, Rauch liegt in der Luft, und Glasscherben bedecken den Boden. Mein Vater ruft nach mir, da er sich nicht befreien kann. Doch ich bleibe stumm.

Glücklicherweise hat er sein speziell für Blinde entwickeltes Smartphone dabei. Aber jetzt muss er 33-mal die Nach-Unten-Taste drücken, um die „SOS“-App auszuwählen und um Hilfe zu bitten. Dabei gibt es 30 andere Apps auf diesem Smartphone, die wichtiger sind als „SOS“.

In meinem Video können Sie sehen, dass ich als Sehender nicht darauf warten muss, dass die Stimme die Einträge vorliest, da ich visuell mehrere App-Namen gleichzeitig erkennen kann. Aber kann eine sehbehinderte Person in Panik- oder Stresssituationen wirklich auswendig wissen, wie oft sie auf welche Taste klicken muss?

Szenario 2: Jemanden anrufen
Gut, dass das Gerät eine „Google-Assistent-Taste“ hat! Mein Vater drückt diese Taste und sagt ins Mikrofon: „Pedram anrufen!“ Der Google-Assistent antwortet gehorsam: „Peter unter Kontakten nicht gefunden!“ Offenbar wird mein Vorname „Pedram“ einfach in „Peter“ umgewandelt, um dann in der Kontaktliste des Androids gesucht zu werden.

Szenario 3: Die Schaltfläche mit dem Mikrofonsymbol in der Suchleiste der Google-App verwenden (Google Speech-to-Text und automatische Suche)
Da mein blinder Vater den Bildschirm nicht sehen kann, muss er mit einer physischen Taste zunächst zu dieser Schaltfläche navigieren und sie dann mit einer anderen physischen „OK“-Taste aktivieren. Das Aktivieren funktioniert, aber die Software lässt die Taste wieder los, obwohl der Finger immer noch darauf bleibt. Speech-to-Text und die anschließende Suche funktionieren somit überhaupt nicht!

Szenario 4: Akkulaufzeit
Auch in diesem Punkt wurden keine Fortschritte erzielt, und die Akkulaufzeit hat sich halbiert bis gedrittelt! Mein Vater musste das vorherige Modell alle 5 bis 10 Tage aufladen, aber jetzt muss er es spätestens alle 3-5 Tage aufladen.

Szenario 5: Komplette Umkehrung der Menüführung
Jedes einzelne Bit und Byte wurde umgedreht. Der neue Irrgarten, auch bekannt als Menü, ist völlig anders. Alles, was über Jahre hinweg gelernt und gemerkt wurde, muss mein Vater vergessen, da es nun absolut nutzlos ist. Offenbar hat niemand eine Alternative zum neuen Menü in Betracht gezogen!

Andere Szenarien wie die merkwürdige Übersetzung und Aussprache englischer Texte, unerwartete Namen und beschreibungslose Pop-up-Dialoge aller Art sowie ständige Abstürze der „Text-to-Speech“-Software (die einen Neustart notwendig machen) lasse ich hier außer Acht.

Diesem Produkt hätten folgende Dinge nicht geschadet:

  1. Benutzerforschung
  2. Definition der Zielgruppe
  3. nutzerzentriertes Design (UCD)
  4. Entwicklung von Anwendungsfällen

Damit „Fehlanpassungen“ und die Unzufriedenheit der Benutzer bereits früh in der Entwicklung vermieden worden wären.

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.

Kapitän! Oh mein Kapitän!

„Auf deinem Schiff, wäre ich ungern. Weder als Passagier noch als Matrose!“

Eine Firma ist wie ein Schiff, und der Chef/CEO/Geschäftsführer sein Kapitän.

Wenn der Kapitän ständig zu 100% belastet ist, für tausend Dinge zuständig, unterschiedlichste Dinge aus unterschiedlichste Bereiche erledigen muss, sich mehr und schneller als seiner Besatzung/Mannschaft bewegen muss, für keine wichtige Informationen, nicht einmal für „Eisberg voraus!“ Warnungen Zeit hat…. dann braucht man sich über seine Entscheidungen nicht wundern.

Er/Sie ist gar nicht im Stande richtige oder optimale Entscheidungen zu treffen, denn… er/sie hat keine Zeit.
Ich habe noch nie auf einem Schiff, einen Kapitän gesehen, der ständig im Stress und Bewegung ist, und tausend unterschiedliche Dinge aus unterschiedlichste Bereiche erledigt.

Ein Kapitän strahlt Ruhe und Zuversicht aus, hat den Überblick, hat die Zeit zum Überlegen, Zeit für Gespräche und Beratung mit seiner Mannschaft/Besatzung, Zeit fürs Analysieren, und nimmt sich die Zeit für Warnungen wie „Eisberg Voraus!“.

Die Geschichte von …

Die Geschichte ist ein Lehrer, ohne Schüler.
Antonio Gramsci

Oft ist es gut, zu wissen wie etwas entstanden ist, oder welches Problem zu ein bestimmtes Werkzeug, Konzept oder Paradigma geführt hat, und welche Idee dahinter steckt.

Ein paar Beispiele:

Die Rolltreppe wurde einst erfunden, um die Passagiere schneller in/aus die (U-)Bahn-Station zu befördern. Dass die Passagiere darauf weiter gehen (Summation der Geh-Geschwindigkeit + Rolltreppen-Geschwindigkeit) und NICHT stehen bleiben sollten, haben die Passagiere nicht mitbekommen oder nicht verstanden.

Der Computer-Führerschein-Test wurde einst eingeführt, um 1. die theoretischen Tests einheitlich zu machen, und 2. Kosten (Beamten von Verkehrs-Ministerium) zu sparen sowie Verwaltungs-Aufwand zu reduzieren (Internet + Datenbank statt Termine und Papiere). Seit Einführung der Computer-Führerschein-Tests lernen die Fahrschüler die richtigen Antworten zu gezeigten Bilder und Fragen auswendig. Sie lernen für die (bekannten) Test-Fragen/-Bilder, nicht mehr! Folgende Fragen können diese nicht beantworten:
Worum geht es bei all den Geboten und Verboten, bzw. was ist der Hauptgedanke von all dem? (damit der Verkehr möglichst für alle Teilnehmer immer im Fluss bleibt und niemals zum Stillstand kommt).
Warum steht bei der Einfahrt in ein Kreisverkehr (meistens) ein „Vorrang geben“ Schild? (weil in Worst-Case-Szenario es dazu kommen kann, dass niemand aus dem Kreisverkehr rausfahren und deshalb auch niemand mehr reinfahren kann = Stillstand schlimmsten Art! Es geht wie immer um das Garantieren des Verkehrsflusses für möglichst alle Teilnehmer)
Warum soll man sich an einer Kreuzung möglichst rechts einordnen, wenn man nach rechts abbiegen will, und möglichst links, wenn man nach links abbiegen will? (damit andere, die in die andere Richtung abbiegen möchten Platz haben und nicht unnötig dahinter warten müssen. Garantieren des Verkehrsflusses! Lange Auto-Schlangen/Staus möglichst bald verhindern!)
Warum soll man an einer Kreuzung zügig abbiegen und auch beschleunigen? (damit N andere Teilnehmer nicht stark bremsen müssen, und dadurch Reduktion von Kollisions- und Auffahrunfälle zu erreichen)
Warum werden an manchen Abschnitten der Autobahnen, die Höchst-Geschwindigkeit auf 100, 80 oder 70 km/h beschränkt? (wegen Autobahn-Ausfahrt(en) oder -Abzweige, damit sich alle rechtzeitig richtig und sicher einordnen können, ausgenommen Polizei-/Pass-Kontrolle, Umweltschutz und Reduktion von Lärm in stark besiedelten Abschnitte)

Warum wurden die ersten Computer/Rechenhilfsmittel (Abakus, Logarithmus-Schieber/-Tabellen, mechanische Rechner udg.) erfunden? (um menschliche Fehler zu vermeiden)


Teamwork

Software-Entwickler die immer in Teams gearbeitet haben, sind besser als jene die ausschließlich alleine Programmiert haben. Warum?

Wenn Anton, Bert und Christian in Team arbeiten: Zahn + Rad = Zahnrad + Christians Idee = Planetengetriebe

Weil:

  • Vier Augen sehen mehr als zwei. Sechs Augen sehen mehr als vier, usw. usf.
  • Zwei Köpfe denken mehr als einem Kopf. Drei Köpfe denken mehr als zwei usw. usf.
  • Ideen: die Kollegen haben manchmal bessere Ideen
  • Schneller ans Ziel kommen 1: ein Kollege kennt schon die Lösung zu einem Problem
  • Schneller ans Ziel kommen 2: die Arbeit kann aufgeteilt werden
  • Code-Review: die Kollegen von Team machen einem auf die Fehler udg. aufmerksam. Man lernt, und bessert sich.
  • Lernkurve: in Team lernt man viel mehr Dinge in viel kürzere Zeit
  • Erfahrung: ein Kollege hat bereits Erfahrung mit XY und teilt diese
  • Disziplin: um mit den Anderen am gleichen Code, Komponenten etc. zu arbeiten, muss man sich an bestimmte interne Standards, Regeln und Vorschriften einhalten (Naming, Coding, Commenting, Code-Style, Versioning, Change-Logs, Git/Subversion Commits, Packaging, …)
  • Bessere, solidere APIs und Code: kein Team-Mitglied kann Ad hoc Signaturen ändern, Dinge umbenennen oder zu verschieben („Rambo-Programmierung“). Jedes Team-Mitglied ist gezwungen:
    1. mit den Anderen zu Kommunizieren (Vorgänge absprechen)
    2. sich Dinge (Namen, Kommentare, Algorithmen etc.) vorher sehr gut überlegen, da die Anderen ihren Code auch ändern müssen
  • Schnellere Erfolgserlebnisse in viel kürzere Zeiten: da Einzelteile schneller entwickelt werden, hat man in viel kürzeren Zeitabständen Erfolgserlebnisse. Als Einzelkämpfer dauert es viel länger, um ein Teil-Erfolg zu feiern.
  • Motivation: Erfolgserlebnisse in kurzen Zeitabständen motivieren (Erfolgserlebnisse in sehr langen Zeitabständen demotivieren!)
  • Es macht mehr Spaß!
  • Man entwickelt sich weiter: Ein Entwickler in ein N-köpfiges (N > 1) Team vermehrt, vertieft und verbessert seine Fähigkeiten, Kenntnisse, Können und Still mit Faktor N in gleicher Zeitraum als der Einzelkämpfer

Sich in die Arbeit eines Profis einmischen

Was passiert, wenn jemand, der irgendwann mal Code geschrieben hat, jedoch von Software-Engineering kaum eine Ahnung hat, sich in die Arbeit von professionellen Software-Entwicklern einmischt und für denen Entscheidungen trifft?

Gegenfrage 1: sagt er jeden Tag dem Schulbus-Chauffeur, der seine Kinder zur Schule fährt, wie er den Bus zu fahren hat, wann und wo er abbiegen oder anhalten muss, nur weil er einen Führerschein hat und mit seinem Auto fährt?
Gegenfrage 2: geht er jedes Mal, wenn er in Urlaub fliegt ins Cockpit, und sagt den Piloten wie diese zu Fliegen/Landen haben, nur weil er mal als Kind Drachen (Kite) in die Luft steigen lassen hat, oder ob und zu mit seinem Quadrocopter spielt?
Fazit: Lieber Chefs/CEOs/CFOs/Manager; Bitte seid Restaurant-Gäste! Gebt eure Bestellung auf! Lasst euch bedienen, denn der Koch weiß wie er zu Kochen hat.
Anders formuliert: lasst Profis ihre Arbeit machen! Sagt denen WAS das Ding tun soll und nicht WIE sie dieses Ding machen sollen.

Software-Engineering, gut gedacht vs. gemacht

Gute vs. Schlechte Software-Engineering

Eigenschaften von gutem Software-Engineering:

  1. Man nimmt sich genug Zeit fürs Vordenken, Analysieren, Recherche, Review, Planen und Einteilen der Aufgaben + Meilensteine + Abhängigkeiten
  2. Anforderungsanalyse hat keine Lücken, enthält ausschließlich feste, genau, eindeutig definierte Formulierungen
  3. Es gibt ein Pflichtenheft speziell für die Software-Entwickler (es gibt keine offenen Fragen von Software-Entwickler nach Projekt-Beginn)
  4. Abhängigkeiten, Risiken udg. werden abgewogen und verwaltet.
  5. Architektur-, Komponenten- und API-Design wurden genauestens überlegt und entworfen (kein Reengineering danach notwendig)
  6. Man plant Tests: Was, Wann, Worauf, Wie und Womit wird getestet
  7. Wenn Kunden sich Kleinigkeiten wünschen, kann das sofort und in kurze Zeit erledigt werden (keine Staatsaffäre)
  8. Projekt ist sehr wirtschaftlich, man macht satte Gewinne
  9. SW Komponenten können 1:1, oder mit geringer Anpassung, für weitere Projekte verwendet werden
  10. Die Software-Komponenten haben eine sehr hohe Qualität
  11. Die SW-Dokumentationen behalten für sehr lange Zeit (Jahre) ihre Gültigkeit
Wenn genug vorgedacht und geplant wird, muss danach nicht viel/lange implementiert werden.

Eigenschaften von schlechte/mangelhafte/nicht-Existenz von Software-Engineering:

  1. Man nimmt sich kaum Zeit fürs Vordenken, macht kaum Analysen, recherchiert wenig/kaum, lässt keine Reviews machen, plant grob/falsch, Einteilung und Verteilung der Aufgaben passiert Ad hoc nach dem Projekt-Beginn (während Implementierung, (Pseudo-)Testung etc.
  2. Anforderungsanalyse hat große Lücken und ist sehr schwammige, offene, mehrdeutig interpretierbare Formulierungen
  3. Es gibt kein Pflichtenheft für SW Entwickler! Man nimmt das gleiche Pflichtenheft für Kunde und gibt es Software-Entwickler.
  4. Über Abhängigkeiten und Risiken hat man sich kaum oder gar keine Gedanken gemacht, geschweige dessen Abschätzung oder gar Verwaltung
  5. Architektur-, Komponenten- und API-Design entstehen nach Projekt-Beginn, währen Implementierung, und deshalb muss immer wieder Reengineering und Redesign betrieben werden
  6. Tests werden nicht geplant. Test-Units entstehen während, oder gar am Ende der Implementierung, müssen immer wieder ergänzt und/oder „angepasst“ werden („Was nicht passt, wird passend gemacht!“). Zum Testen spielt ein Mitarbeiter so lange herum, bis vielleicht irgendwas nicht so läuft, wie man will, oder irgendwas sich ergibt/zeigt …
  7. Gott bewahre, ein Kunde wünscht sich eine Kleinigkeit. Das kommt eine Staatsaffäre gleich. Es ist so als ob Mount Everest versetzt werden muss. Kein Byte bleibt auf dem Anderen. Jedes Bit wird umgedreht. Reengineerings nach Reengineerings. Überstunden werden notwendig. Andere Projekte werden die Entwickler entzogen … Die Kosten/LOC explodieren!
  8. Das Projekt wirft, wenn überhaupt, gerade noch, ein paar Euros als Gewinn ab, oder die Fa. muss sogar Pönale zahlen
  9. Verärgerte Kunden beschweren sich immer wieder über Bugs/Fehler (Man hat denen Bananaware verkauft), Folge-Projekte bleiben aus
  10. Die SW-Komponenten haben kaum, oder sehr geringe Qualität
  11. Die SW-Komponenten müssen für weitere Projekte grob verändert, oder gar neugeschrieben werden
  12. Änderungen an eine Software-Komponente zwingt die Änderung viele andere Software-Komponenten (Domino-Effekt)
  13. SW-Dokumentationen (falls vorhanden), verlieren ihren Wert, da sich viel zu viel geändert hat, und müssen um oder komplett neugeschrieben werden
Wenn nicht genug Zeit fürs Vordenken und Planen genommen wird, dann muss man viel mehr Zeit für Reengineering und Überstunden in Kauf nehmen

Flache Hierarchie

Ad hoc, ist keine flache Hierarchie!
Sofort zur Tastatur greifen, ist keine flache Hierarchie!
Chaos ist keine flache Hierarchie!
Jeder ist für tausend Dinge zuständig, ist keine flache Hierarchie!
Jeder tut, was er/sie will, ist keine flache Hierarchie!
Ständig im Fluss der Gedanken unterbrochen werden (Telefon, E-Mail, Meeting, Kollegen im Stress, …), ist keine flache Hierarchie!
Agile ist keine flache Hierarchie!
SCRUM ist keine flache Hierarchie! (Theorie zur „Flat Hierarchy“ wurde 1963 in USA von einem Ökonomen erfunden)
Mangel an Projekt-Verwaltung ist keine flache Hierarchie!
Mangel an Riskmanagement ist keine flache Hierarchie!
Mangel an Ressourcen-Planung ist keine flache Hierarchie!
Schlechtes, unvollständiges Pflichtenheft mit schwammigen Formulierungen, ohne Review, ist keine flache Hierarchie!
Mangel an Anforderungsanalyse ist keine flache Hierarchie!
Flache Hierarchie wird chaotischer gegessen als gekocht!

Warum wendet keine Armee der Welt, die flache Hierarchie? Bei Militär sind Effizienz, Geschwindigkeit und Befehlskette extrem wichtig. Warum haben sie keine flache Hierarchie?

Simulator

Die Vortäuschung, die Verstellung, von lat. simulatio: die Verstellung, die Heuchelei, die Täuschung, das Vorschützen (eines Sachverhalts), die Vorspiegelung, der Vorwand, Die Vorschiebung; lat. similis: ähnlich, gleichartig, gleich.
Eine Simulation gaukelt das Vorhandensein von Etwas, das nicht da ist.

Ein Simulator (Software), vor allem „Dummy“ Simulator, spart auf langer Sicht, Unmengen an Raum, Zeit, Energie, Kabel, Konfigurationen, Installationen etc. etc. und Kosten. Ein Simulator macht einem unabhängig von realem Ding, und man kann sich auf seine Business-Logik konzentrieren.

ACHTUNG: Natürlich sollte irgendwann mal die Software (Business Logik) mit dem echten Ding auch auf Herz und Nieren getestet/geprüft werden, bevor es geliefert wird, oder ins Produktions-System eingesetzt wird!

Modelle

Ein Modell ist eine stark reduzierte, abstrakte Abbildung der Wirklichkeit. Es ist absichtlich unvollständig.

In jenem Reich erlangte die Kunst der Kartografie eine solche Vollkommenheit, dass die Karte einer einzigen Provinz den Raum einer Stadt einnahm und die Karte des Reichs den einer Provinz. Mit der Zeit befriedigten diese maßlosen Karten nicht länger, und die Kollegs der Kartografen erstellten eine Karte des Reiches, die die Größe des Reiches besaß und sich mit ihm in jedem Punkte deckte.
(Jorge Luis Borges, „Von der Strenge der Wissenschaft“ in: Universalgeschichte der Niedertracht und andere Prosastücke, Ffm-Berlin-Wien, ISBN 978-3548029146)

Was ist ein Software-Entwickler oder Techniker der Nichts dokumentiert für eine Firma?

Kurz: Heroin!

Er/Sie macht die Kollegen und die Firma von sich abhängig.

Was passiert, wenn:

  • Dieser Kollege die Firma verlässt?
  • Er längere Zeit krank ist?
  • Er in Pension geht oder stirbt?

Können andere Kollegen die Köpfe zusammenstecken und herausfinden wie seine Komponenten funktionieren? Wie diese sich verhalten oder zu benutzen seien? Oder müssen die Komponenten (die eigenen Produkte der Firma) mithilfe von Reverse-Engineering auf Funktionsweise analysiert werden? Müssen diese Neu/nochmal (von null auf) entwickelt werden?
Muss der gesamte Code gelesen und verstanden werden?
Was kostet die Dokumentation an Zeit und Geld für eine Firma? (A)
Was kostet das Reverse-Engineering des eigenen Produktes + dessen Neu-Entwicklung und/oder lesen des gesamten Codes? (B)
Welche Kosten sind höher: A oder B?
Welche (A oder B) bringt größere, längere und teurere Kaskadeneffekte (Zeitpläne und Ressourcen-Teilung/-Planung, Fertigstellungs-Termine bei parallel laufenden Projekte) mit sich?
Welche (A oder B) bringt die Termine durcheinander, sorgt/stiftet/produziert Chaos, macht Kunden unzufrieden?
Wer zahlt für die entstandene Kosten und Ressourcen-Verbrauch für die Entwicklung eines Produktes das nicht verwendet/eingesetzt werden kann?
Wer zahlt für die entstandene Überstunden bei B?
Wer zahlt für die entstandenen Pönalen/Vertragsstrafen durch B bei N andere Projekte?

Hier eine einfache Milchmädchen-Rechnung (+Diagramm) für besseres Verständnis:


Naive Annahmen:
1. wir leben in einer perfekten Welt (Nichts geht schief, man muss auf Nichts warten, es gibt keine Bugs, niemand wird Krank, keiner nimmt sich Urlaub, … es gibt keine negativen Überraschungen)
2. die Projekte sind voneinander unabhängig und dauern alle gleich (exakt, nur 30 Tage)

Wie man aus dem Diagramm (für eine „perfekte“ Welt) sieht: Die Fertigstellung jedes Projekts verschiebt sich um 15 Tage (Dauer der Neuentwicklung von Komponente/System des Projekts ganz oben) um 15 Tagen nach hinten!
Das bedeutet für alle N Projekte: N × 15 Tage.
In unserem Beispiel, bei 3 Projekten, bedeutet das 45 Tage (eineinhalb Monate) insgesamt.

Wir leben aber in keine perfekte Welt!


1. Manche Projekte sind voneinander abhängig (Projekt A ist von Projekt B abhängig, und Projekt B ist von Projekt C abhängig, usw.): A ⇒ B ⇒ C ⇒ …
2. Krankheit, Urlaub, Todesfall
3. Verzögerung durch Bugs (z. B. Memoryleak)
4. zuständiger Fachexperte für XYZ, der Mitarbeiter X, ist auf einer Baustelle von einem Kunden in Land Y und kommt erst in einer Woche zurück
5. Wegen Covid-19, einem Schiff das in Suezkanal feststeckt, Produktionsverzögerung, Lieferschwierigkeiten für eine Hardware-Komponente, kann man Projekt XY nicht fertigstellen oder testen
6. Die Firma VUDU wird an Firma CONYAK verkauft und ändert die Lizenzierungen für das KI-System von VUDU. Das System muss nun ersetzt werden, oder darauf muss komplett verzichtet werden
7. Es stellt sich in reale Umgebung (Prototyp-System) heraus, dass externes/gekauftes System XYZ für die Aufgabe ABC ungeeignet ist oder dessen Laufzeitkomplexität viel zu hoch als erwartet ist (z. B. Taktzeiten können nicht eingehalten werden, in zeitkritischen Systemen werden harte Zeitschranken durchbrochen)
8. Es wurde aufgrund falscher Annahme(n) viel Code geschrieben, jedoch bei Developer-Tests stellt man am Ende fest: XYZ ist gar nicht imstande ABC zu tun
10. Unterschiedliche Softwareentwickler arbeiten an unterschiedliche Projekte und haben von andere Projekte, dessen Lösungsansätze, Paradigmen und/oder Konzepte keine Ahnung
11. Es gibt Spezialisten für Teilbereiche, nicht jeder kann alles, was der Andere kann. Der Spezialist wird aber für Projekt X benötigt und kann sich nicht auch noch um andere Projekte (Aufgaben) gleichzeitig kümmern
12. Der Tester bzw. die Test-Abteilung muss sich zuerst um Projekt X kümmern. Projekt Y muss warten bis es zum Testen dran ist
13. … und vieles mehr

Wie man in obigem Diagramm sieht:
Die Neuentwicklung des Komponenten/Systems (ganz oben) verursacht enorme Chaos und Verzögerung in Projekt 1, was wiederum enorme Chaos und Verzögerung bei Projekt 2 verursacht.
Da das Projekt 3 von Projekt 2 abhängig ist, braucht man sich nicht wundern, dass die Entwicklung dessen erst nach dessen Liefertermin gestartet werden kann. Obwohl für die Liefertermine für jedes Produkt 10 Tage als Puffer geplant waren (was ich in der Realität leider noch nie erlebt habe!).
Das ist die Folge von: Nichts dokumentieren (weil „die Kunden nicht fürs Dokumentieren Zahlen“).

Welche Bedeutung hat „Bei uns funktioniert es.“ für Kunden?

Therac 25

Kurz: Nichts/keine!

Warum?
Dazu folgende (wahre) Geschichte:
Es gab mal eine kanadische Firma namens AECL (Atomic Energie of Canada Limited), welche medizinische Bestrahlungsgeräte baute. Unter anderem das Therac 25.
Das A und O der Bestrahlungsgeräte lautet: Soviel Strahlung wie nötig, so wenig wie möglich!
Immer wieder kontaktierten Mediziner die Firma AECL und beklagten sich über Bestrahlungsüberdosen.
Von der Firma AECL kam stets die gleiche Antwort: „Bei uns funktioniert es“ und „Es muss an euch liegen“.

Mehrere (mind. drei) Patienten sind wegen Bestrahlungsüberdosis durch Therac 25 ums Leben gekommen.
Einige Patienten verloren ihre Glieder nach Not-Amputationen (direkt nach Bestrahlungsüberdosis durch Therac 25), weil das Gewebe an bestrahlte Stelle komplett verbrannt war (= totes Fleisch!).
Einige Patienten könnten nie wieder ihre Extremitäten (Hand, Arm, Fuß, Bein) bewegen oder spüren, da die Nerven durch die Bestrahlungsüberdosis komplett verbrannt waren (= tote Nervenzellen!). Z. B. Marietta, eine 61-jährige Frau aus Georgia, wurde wegen Lymphknoten in 1985 mit 15000Rad statt 200Rad (75-fach höhere Dosis) bestrahlt. Sie könnte nie wieder ihre Schulter oder Arm bewegen oder spüren.

Die Entdeckung der Fehler:
Anmerkung: In USA müssen die Mediziner vor ihrem Medizinstudium ein technische oder naturwissenschaftliches Studium erfolgreich absolviert haben (Dipl.-Ing. früher in Österreich), sonst dürfen sie nicht Medizin studieren.
In einem Krankenhaus in USA, wurde eine Radiologin (die auch Physikstudium absolviert hatte), auf die Bestrahlungsüberdosen durch Therac 25 aufmerksam. Sie notierte die Daten der Vorkommnisse und sah ein Muster darin. Daraufhin bat sie einen Kollegen (Mediziner) der sich mit Elektronik und Computer auskannte um Hilfe.
Sie entwickelten einen systematischen Testplan, und testeten den Therac 25 gründlich. Sie haben gleich mehrere reproduzierbare Fehlverhalten festgestellt und AECL sowie die Behörden informiert. Erst jetzt wurden die Fälle von der Behörde und AECL untersucht!

Die Fehler:
Es wurden mehrere Fehler gefunden:

  1. Mechanischer Fehler!
  2. Mehrdeutige, in die Irre führende Anzeige bzw. Texte/Begriffe
  3. Umständliche Softwarebedienung, nicht automatisierte Kondition-Checks udg. (der User müsste auch für die Software mitdenken, vergleiche dazu TAROM-Flug371 Automatic Throttle System ATS Fehler/Schwäche!)
  4. Race Conditions!
  5. Synchronisations-Fehler (angezeigter neuer Dosis-Wert entsprach nicht den im Speicher für die Bestrahlung angewendeter Wert, d. h. alter Dosis-Wert wurde für die Bestrahlung angewendet)
  6. Zustands-Transitions-Fehler (die Positionierung verschiedene Magneten dauerten 8 Sekunden, die Bestrahlung wurde aber sofort eingeleitet, dadurch hatte jede Bestrahlung 8 Sekunden länger als erwartet gedauert, beginnend an falsche Position/Stelle)
  7. Flags wurden ignoriert (nach grobe Positionierung wurde die Feinpositionierung der Magneten ignoriert)
  8. Fehlermeldungen waren nicht aussagekräftig, waren nicht verständlich dokumentiert, ergaben für die Anwender (Mediziner) keinen Sinn!
  9. usw. usw. usf.

Wie könnte das Alles nur passieren?

  1. Einbildung (Gehabe und Einstellungen wie: „Ich bin so super!“, „Ich bin Perfekt und alle Anderen sind Idioten“, „Ich weiß alles, alle Anderen wissen nichts“ und „Ich bin der beste Programmierer auf der Welt!“, …)
  2. Sätze und Glaubens-Gedanken (statt anständige Tests) wie:
    1. „Es funktioniert.“
    2. „Es hat funktioniert.“
    3. „Bei uns funktioniert es.“
    4. „Es muss an euch liegen.“
  3. „Software-Tests“ von AECL basierten auf Vermutungen und „Schauen wir mal, ob es so funktioniert wie wir uns gedacht haben“, anstatt auf systematische professionelle fundierte Analysen! Das Ziel deren Tests war zu beweisen, dass es funktioniert, und nicht das Finden von Fehler!
  4. Der neue Programmierer nutzte die SW-Komponenten des alten Programmierers (welcher AECL verlassen hatte), ohne wirklich zu wissen, wie diese Entworfen waren, und wie diese richtig einzusetzen waren (Race Conditions, Sync. Fehler, Flags-Änderungen ignorieren udg.)
  5. Unverantwortliche Projekt-Leiter und Manager („Hauptsache Billig!“ Manier) die über die Tragweite ihrer Entscheidungen nicht bewusst waren (und Warnungen der Techniker/Experten ignorieren): nahezu alle Hardware-Überwachungskomponenten des Vorgängermodells wurden entfernt und durch Software-Checks ersetzt (wegen höchstens einige 1000 $ Hardwarekosten haben einige Menschen ihren Leib und Leben verloren! Tolle Kostenreduzierung!)
  6. Bei Therac 25 wurde ein komplett neues eigenes Betriebssystem eingesetzt, welches noch jung war („Kinderkrankheiten“), Fehler enthielt und die AECL Mitarbeiter keine Erfahrungen damit hatten. Kommerzielle Betriebssysteme wären bekannt und auch länger getestet gewesen (Erfahrungswerte, Bekanntheit, Dokumentationen, …). Aber auch hier hat AECL sich „viel Kosten erspart“.

Konsequenzen:
1985-1987 wurden von FDA (Food and Drug Administration, US-Behörde) und CDRH (Center for Devices and Radiological Health, US-Behörde) weitreichende Reformen durchgeführt (Überwachung von Software-Entwicklung und das Testen, sowie Verschärfung der Freigabeprozedur für neue Geräte).

Die Moral der Geschichte:

  1. Hört auf zu denken/sagen „Es funktioniert“ oder „Es hat funktioniert.“
  2. Hört auf zu sagen „Bei uns funktioniert es.“ oder „Es muss an euch liegen.“! Davon kann der Kunde sich Nichts kaufen!
  3. Testet! Testet! Testet! Und zwar gründlich, analytisch, systematisch und fachmännisch. Die Aufgabe von Testen ist Fehler zu finden, und nicht zu beweisen das „es funktioniert“. Es gibt genug Paradigmen, Konzepte, Module, Best Practices, Standards und Konventionen für ein gründliches, systematisches, analytisches, fachmännisches Testen (TDD, Unit-Testing, Test-Doubles, Mocks & Fakes, Digital-Twins, Fehler-Simulatoren, …)

Welche Bedeutung hat „Es funktioniert.“ ?

Ariane 5

Kurz: Nichts/keine.

Warum?
Dazu folgende (wahre) Geschichte:
Es gab mal eine europäische Trägerrakete namens Ariane 4. Diese hatte ein Modul namens SRI (Inertial Reference System), welches für die Berechnung der Flugbahn zuständig war. Das SRI Modul war bestens getestet. Die Mission Ariane 4 war erfolgreich (somit hatte SRI in Produktion-System „funktioniert“).
Dann baute man Ariane 5 mit stärkeren Triebwerke. Da das SRI Modul von Ariane 4 getestet und erfolgreich erprobt war, wurde es einfach in Ariane 5 eingesetzt.
Ergebnis: in Sekunde +41 nach Zündung (Ignition) wurde der automatische Selbstzerstörungsmechanismus von beiden Onboard Computern ausgelöst und zerstörte die Rakete.
Grund:
Ariane 4 Computer war ein 16 Bit System.
Ariane 5 Computer war ein 64 Bit System.
Bei der Berechnung der Flugbahn wurde ein 64 Bit Float Wert (Fließkomma-Zahl) an SRI Modul übergeben ⇒ Stack Overflow!
Die Triebwerke schlugen von der eine (IST-Wert) Richtung in das Extreme, andere Richtung (overflow SOLL-Wert).
Durch die große Masse und hohe Geschwindigkeit (Impuls, Energie) wäre Ariane 5 auseinandergebrochen, weshalb der automatische Selbstzerstörungsmechanismus die kontrollierte Sprengung ausgelöst hat.
Wie man sieht: „Es funktioniert.“, oder „Es hat funktioniert.“ bedeutet rein gar Nichts!
Fun Fact 1:
Nach Sekunde +36 war eine Berechnung der Flugbahn durch das SRI Modul gar nicht notwendig gewesen, und hätte somit von „Haupt-Computern“ abgeschaltet werden können.
Fun Fact 2:
Die Herstellungskosten für die Rakete und die Satelliten beliefen auf ca. 500 Millionen Dollar. Da keine kommerzielle Fracht an Bord war, sondern „nur“ Forschungssatelliten, war der Flug nicht versichert worden.
Fun Fact 3:
Die Entwicklung der Rakete alleine hat 10 Jahre und 7 Milliarden Dollar beansprucht.
Resultat: 10 Jahre Entwicklungszeit + 7.500.000.000 $ wurden nach nur 41 Sekunden vernichtet, weil man sich dachte „Es hat funktioniert.“.

Wer ist ein Profi Software-Entwickler?

Ist jeder, der Zuhause kocht ein Haubenkoch?
Ist jeder der an seinem Auto/Motorrad herumschraubt ein Auto-/KFZ-Mechaniker?
Ist jeder der mit einem Lötkolben in einem Radio/Fernseher herum lötet ein Elektroniker?

Man kann ja selbst Fliesen legen und Küchenregale montieren. Ja! Klar! Aber wer macht es besser und professioneller, mit kaum fataler oder sichtbarer Fehler? Der Profi der das jeden Tag seit zig Jahren macht, oder man selbst?

Conclusio:
Nicht jeder der Code schreibt, ist auch ein professioneller Software-Entwickler!
Software-Entwickler > Programmierer > Code-Schreiber.

Code vs. Buch

Roman/Buch vs. Code/Programm lesen/schreiben:

Jeder kann Bücher lesen. Nicht jeder der Bücher lesen kann, kann auch ein (gutes/Bestseller) Buch schreiben.
Jeder kann Code schreiben. Nicht jeder der Code schreiben kann, kann auch Code lesen.

(Zitat von meinem geschätzten ehemaligen Kollege Manfred)

Damit man ein gutes Buch schreiben kann, muss man viele gute Bücher gelesen haben.
Damit man guter Code schreiben kann, muss man viele (IT) Bücher sowie Code gelesen haben.

Ein Autor bzw. eine Autorin schreibt Bücher für die Leserinnen.
Ein Software-Entwickler schreibt Code für:

  1. Sich selbst, da er/sie es vielleicht in einem Monat oder einem Jahr wieder lesen, verstehen und ändern muss
  2. für seine Kolleginnen, da sie es vielleicht lesen, verstehen und ändern müssen
  3. für die „Nachwelt“ (neue Kolleginnen in der Zukunft, wenn man nicht mehr in der Firma ist)
  4. und zum Schluss für den Compiler und CPU (oder JVM, CLR oder sonstige virtuelle Maschinen)

Wenn die Dämme brechen

In jede Firma, jede Abteilung und auf jedem Tisch und in jedem Kanban-System, gibt es einen unsichtbaren Damm. Hinter dieser Damm sammelt sich ein trüber stinkender Schlamm, bestehend aus all die Fehler, falsch oder schlecht angegangene/gelöste Aufgaben, falsche Annahmen, falsche Entscheidungen, falsch (nicht)kommunizierte oder (nicht)verstandene Dinge, und all die nicht erledigte aber wichtige Dinge.
Irgendwann bricht einer dieser Dämme und der Kaskadeneffekt beginnt. Der Aufgaben-Flut zeigt nun den Schlamm, wie ein Orkan die Existenz der Luft:

  • es müssen immer mehr Entwickler eingestellt werden
  • die Entwickler müssen immer mehr Code von bestehenden Komponenten ändern (oder hinzufügen)
  • die APIs und Framework-Komponenten ändern sich wöchentlich oder gar täglich
  • die Entwickler betreiben immer wieder Reengineering
  • die Entwickler müssen immer mehr Überstunden machen
  • die Entwickler lesen mehr Code (Implementierung-Details) als sie schreiben (der Kunde zahlt nur fürs Schreiben!)
  • die Entwickler werden täglich, ja sogar stündlich über bestimmte Bugs oder Problemen bei Kunden befragt
  • die Entwickler müssen immer mehr Telefonate, E-Mails udg. beantworten, und werden dadurch in ihrem Gedanken-Fluss unterbrochen
  • die Entwickler können sich nicht einmal für zwei Stunden, Zeit für tiefgründiges Nachdenken/Überlegen nehmen
  • wöchentlich, täglich, ja sogar stündlich, gibt es neue Versionen
  • der Compiler benötigt immer länger fürs Übersetzen (eine Sekunde ist für einen Computer eine Ewigkeit!), die Startzeit mal zwei!
  • das Programm benötigt immer mehr Speicher (HDD & RAM)
  • das Programm wird immer langsamer, und dadurch steigen die Wahrscheinlichkeiten für Nebeneffekte und neue (unerwünschte) Verhalten (vor allem bei komplexen, zeitkritischen Systemen)
  • die benötigten PCs für die Software benötigen immer mehr CPUs (Cores)
  • bei kleinen Anpassungen/Änderungen für einen Kunden, beschwert sich mindestens ein anderer Kunde über neuen Fehler (von einer Funktion, die bis dahin immer tadellos funktionierte)
  • Hotline ist ständig vollbeschäftigt, muss lange Telefonate mit enttäuschten/verärgerten Kunden/User führen
  • Techniker, Service-, Troubleshooting- und 3rd-Level-Support-Kollegen haben immer mehr zu tun, oder sind ebenfalls ständig beschäftigt
  • man sucht immer mehr und länger nach Fehler/Bugs und unerwartetes/unerwünschtes Verhalten
  • man benötigt für egal welche Tests, immer irgendwelche Hardware (SPS/PLCs, Sensoren, Netzteile, USB-Dongles, spezielles Kabel udg.) und kann diese Tests nicht durchführen, wenn das eine oder andere Hardware fehlt
  • und vieles mehr

Jetzt, wo der Damm gebrochen ist, ist man die Aufgaben-Flut ausgeliefert. Man hat keinerlei Kontrolle über die Aufgaben, wie ein Autofahrer mit über 100 km/h auf Glatteis. Ab jetzt kann man nur taktisch, Ad hoc und „husch husch“ (eher „Pfusch Pfusch“) auf die Aufgaben reagieren. Für strategisches und langfristiges Planen, Entwerfen und Programmieren, sowie dessen (Teil)Automatisierung ist es erstens zu spät, und zweitens keine Zeit da, da die Kunden warten. Das Dach brennt! Die Entwickler springen von einer dringenden Aufgabe zu Nächste, wie ein Ping-Pong-Ball. Die Entwickler laufen gestresst von einem Bugfix/Reengineering zum Anderen, wie eine Feuerwehr-Truppe die zig Brände an unterschiedlichen Orten gleichzeitig löschen muss.
Die Kosten steigen. Für neue Projekte ist kaum Zeit da. Für Modernisierung (z. B. Umstieg von Windows Forms auf WPF/UWP) schon gar nicht. Ein Liefertermin nach dem Anderen wird überschritten. Die Firma beginnt nun auch noch Pönalen zu zahlen. Die Kunden sind verärgert und unzufrieden. Die Inhaber, CEOs, CFOs, Abteilungsleiter und Team-Leader sind gestresst und verärgert. Die Entwickler auch. Eine: lose-lose-lose Situation.
Man hat sich Niemals-Endende-Baustellen geschaffen.
Da kann man sich selbst gratulieren.

The Good, the Bad and the Ugly Code(r)

Hässlicher Code ist wie ein Kondom, Taschentuch oder Toilettenpapier. Man kann es nur einmal verwenden.

Guter Code hat einen Mehrwert. Wie die Weihnachtskeks-Schablonen/-Formen kann man ihn immer wieder verwenden/einsetzen.

Nomen est omen: Eine Funktion oder Prozedur tut genau das, was der Name sagt, nicht mehr und nicht weniger. Gilt auch für Namensräume, Klassen, Events, Variablen etc. Der Name muss 100%ig selbsterklärend, eindeutig und unmissverständlich sein.

Eleganter Code ist: kurz, klar, einfach, eindeutig, einprägsam und effizient. Alles andere ist plumper (dahin-gerotzter) Code.

Intelligente Software-Entwickler schreiben den einfachsten, kürzesten und flachsten Code (Eleganz!).
Schlechte Software-Entwickler schreiben die kompliziertesten, längsten Zeilen und mehrfach verschachtelter Code.

Faule, aber clevere Software-Entwickler haben jeden Tag weniger zu tun als der Tag zuvor, während fleißige, aber schlechte Software-Entwickler jeden Tag gleich viel oder sogar mehr als der Tag zuvor tun müssen. (Siehe „Wenn die Dämme brechen“!)

Guter Code wird getestet, denn nur guter Code kann getestet werden. Schlechter Code kann gar nicht getestet werden. Die Aussagekraft der Tests von schlechtem Code = 0.

Code-Optimierung erfolgt erst nach vollständiger Implementierung und erfolgreichem Testen, nicht davor oder währenddessen.

Ausbildung, Bildung, Einbildung

Das Gegenteil von Wissen ist nicht Ignoranz (Unwissenheit), sondern fester Glaube/Überzeugung an falsche Informationen/Theorien.

Es gibt Bildung, Ausbildung und… Einbildung:
Mit Bildung kann man selbstständig kritisch denken, aber kein Brot backen oder Fahrrad bauen (Philosophie, Literatur, schönen Künste,…).
Mit Ausbildung kann man Brot backen und Fahrrad bauen, aber nicht selbstständig kritisch denken (Lehre, Automatisierungs-Studium,…).
Einbildung macht Bildung und Ausbildung zunichte. Einbildung benötigt keine Lehranstalt für höchste Zeugnisse. Jeder kann sich Einbilden, was er/sie will.

Ignoranz, Ausbildung, Bildung, Einbildung

To comment, or not to comment – that is the question

Eine kurze Geschichte übers Kommentieren und Kommentare

Ich wünsche die Kollegen beim Neuschreiben des Codes in C, C++, C#, Java,… oder WasAuchImmer++ viel Geduld, Kraft und Nervenstärke.
Wenn Kommentare genauso kryptisch sind, wie der Code
Was machen diese 15 Zeilen?
Man kann die Kommentare übersetzen und erahnen was diese Zeilen tun

Back to the Future…
Kommentare sind wichtige Informationen für die Zukunft.
Kommentare sind wichtige Informationen aus der Vergangenheit.
Kommentare sind Notizen/Erklärungs-Ergänzungen für sich selbst, Kolleginnen und die Nachwelt (neue Kolleginnen, wenn man nicht mehr in der Firma (oder am Leben) ist).

Ich lese immer wieder Sätze mit Rufzeichen am Ende, wie „Jede Code-Zeile muss kommentiert werden!“, oder „Pro Methode, mindestens drei Zeilen Kommentare!“ usw.

An der Uni hieß es „Alles muss kommentiert werden!“.

Dann hieß es (eine Show namens „Linux Nerds vs. Geeks“ glaube ich) „Wenn man schönen/guten Code schreibt, braucht man keine Kommentare“ (sagte der Linux Grafik-Programmierer-Guru!).

Irgendwann sagte ein ehemaliger Kollege „Kommentare verwirren nur“ und dass „Nur Amateure und Doofis kommentieren“ …

Mein derzeitiger Standpunkt ist:

  1. Extrem ist und bleibt extrem. Daher entscheide ich mich für die goldene Mitte.
  2. Bevor ich Kommentiere stelle ich mir folgende Fragen:
    1. Muss ich Kommentieren?
    2. Reicht der Name nicht?
    3. Ist der Name gut gewählt?
    4. Sollte ich nicht lieber den Namen ändern?
    5. Wie groß ist der Informationsgehalt des Kommentars?
    6. Bietet der Kommentar eine zusätzliche oder ergänzende Information, die sonst nicht (oder sehr schwer) zu lesen/sehen/wissen (Code) wäre?
    7. Erleichtert/Verkürzt der Kommentar die Suche/Recherche oder das Verständnis des Algorithmus?
    8. Lässt der Kommentar Raum für falsche Interpretationen zu?
    9. Hilft der Kommentar Fehler zu minimieren, oder verursacht es mehr Fehler durch Missverständnis?

Nehmen wir den (C#) Code von Unten als Beispiel und stellen wir uns gemeinsam pro Kommentar die obigen neun Fragen unter Punkt zwei:

public class Person
{
    /// <summary>
    /// Gets/Sets the ID of Person.
    /// </summary>
    public int ID { get; set; }

    /// <summary>
    /// Gets/Sets the first/given name of Person.
    /// </summary>
    public string FirstName { get; set; }

    /// <summary>
    /// Gets/Sets the last/second name of Person.
    /// </summary>
    public string LastName { get; set; }

    /// <summary>
    /// Gets/Sets the day of birth of Person.
    /// </summary>
    public DateTime BirthDay { get; set; }

    /// <summary>
    /// Returns the whole/full name beginning with FirstName then LastName in uppercase.
    /// </summary>
    /// <returns></returns>
    public string GetName()
    {
        // todo: check!
        return $"{FirstName} {LastName.ToUpper()}"; // NG! PGH 2021-07-05 V0.8.15
    }
}

Die Property-Namen sagen eindeutig, unmissverständlich und klar aus, was sie beinhalten, und deren Kommentare haben/bringen keine zusätzliche/ergänzende Informationen… Also ⇒ Weg damit!

Der Kommentar von der Methode „GetName“ möchte, und MUSS, etwas erklären, was der Name leider nicht tut. Zusätzlich verwirrt dieser Kommentar.
Innerhalb der Methode „GetName“ steht ein „todo“ Kommentar, was kein Mensch entschlüsseln kann: „check!“ Check-What? Was soll gecheckt/überprüft werden FirstName, LastName oder Return-Value (string)?
Am Ende der Return-Zeile steht wieder kryptische Buchstaben-Suppe:

  1. NG!“ steht für…??? No Guns? No Game? Next Generation? Not Good? No Grade? Network Grid?
  2. Danach steht „PGH„, meine Initialien plus Datum und anscheinend eine Version:
    1. Gibt es für sowas Versionsverwaltungs-Systemen (CVS, SVN und GIT). Dort kann man all das lesen, von Anbeginn der Zeit (Projekt-Geburt) bis zum letzten Commit: Wer (Name, E-Mail-Adresse) hat, wann (Datum + Uhrzeit mit Millisekunden) was (Verzeichnis, Datei, Zeile) in welche Version geändert (gelöscht, hinzugefügt, umbenannt, ergänzt, entfernt,…) hat.
    2. Was sollen die Kolleginnen damit anfangen? Mehrwert? Informationsgehalt?

Das Ganze könnte man auch so schreiben:

public class Person
{
    public int ID { get; set; }
    public string FirstName { get; set; }
    public string LastName { get; set; }
    public DateTime BirthDay { get; set; }

    /// <summary>
    /// Returns full name, like: "John DOE", "Alice BOYLE".
    /// </summary>
    /// <returns></returns>
    public string GetFullName()
    {
        return $"{FirstName} {LastName?.ToUpper()}";
    }
}

Ich habe diese Beispiele nicht aus der Luft gegriffen.
Ähnliche, und teilweise noch schlimmere Fälle aus der Praxis (was mir unter die Augen gekommen sind) werde ich noch hinzufügen. Entweder hier oder im neuen Beitrag.

Ugly vs Clean Code (zum Aufwärmen)

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;

namespace Ugly.Code
{
    public class GeoCalc
    {
        public double GetCS(double value)
        {

            double val1;
            double calc;


            val1 = value;
            calc = Math.Pow(val1, 2) * Math.PI;


            return calc;


        }

        public double GetSS(double value)
        {

            double val1;
            double calc;


            val1 = value;
            calc = Math.Pow(val1, 2);


            return calc;
        }

        // Some other methods...
    }
}

Warum ist der Code oben „Ugly“?

  1. Ungenutzte „using“ Zeilen
  2. Der Klassen-Name sagt nicht, was die Klasse enthält/anbietet/tut
  3. Die Methoden-Namen sagen nicht, was sie tun oder berechnen/zurückliefern
  4. Die Parameter-Namen sagen nicht, was sie enthalten
  5. Die lokalen Variable-Namen sagen nicht, was sie enthalten
  6. Lokale Variablen kaschieren die Parameter und dessen Werte, machen den Algorithmus schwer verständlich
  7. Unnötige Leerzeilen verlängern unnötig die Methode. Man muss mehr scrollen und mit den Augen rauf & runterschauen.

Die Klasse „GeoCalc“ von Oben, könnte man auch so schreiben:

using System;

namespace Clean.Code
{
    public class GeometryCalculator
    {
        public double CalculateCircleSurface(double radiusLength)
        {
            return radiusLength * radiusLength * Math.PI;
        }


        public double CalculateSquareSurface(double sideLength)
        {
            return sideLength * sideLength;
        }

        // Some other methods...
    }
}