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.

Navigationsstrategien für den Erfolg: Von Autobahnstau zu Badestränden – Irrwege frühzeitig erkennen, bevor sie richtig kostspielig werden

Fehlentscheidungen und Entwicklungsfehler in einem Unternehmen oder Projekt lassen sich metaphorisch mit dem Verpassen einer Autobahnabfahrt oder dem falschen Abbiegen in einer unbekannten Großstadt vergleichen.

Frühzeitige Erkennung und konsequentes Handeln bei Fehlern, Fehlentscheidungen und Fehlentwicklungen in Konzepten, Produkten, Projekten oder sogar bei der Unternehmensexpansion führen zu geringeren Kosten und einem reduzierten Zeitaufwand für die erforderliche Korrektur.

Wenn man stur weiterfährt und dabei alle Warnsignale herunterspielt und ignoriert, sollte man sich nicht verwundern, wenn man mitten in der Nacht mit leerem Tank an einem abgelegenen Ort ohne zivilisatorische Einrichtungen und Mobilfunkempfang feststeckt.

Die unnötig verstrichene Fahrzeit, der verpasste Sonnenschein und die Kosten für den verschwendeten Kraftstoff hätten stattdessen an einem malerischen Badestrand genossen werden können, hätte man sich lediglich die Zeit genommen, kurz anzuhalten und einen Ortskundigen nach dem Weg zu fragen.

Es mag möglich sein, die exponentiell steigenden Kosten im Verhältnis zur vergangenen Zeit zu bewältigen, JEDOCH…

  1. Kann die Komplexität dieser Herausforderungen ebenso erfolgreich gemeistert werden?
  2. Müssen die Modernisierung des Unternehmens und die Innovation der Produkte aufgeschoben werden?
  3. Ruhen die Mitbewerber in Mitleid oder machen sie weiterhin Fortschritte?

Dimensionierung und Planung von Software und Fußgängerbrücken

Software:
Am Anfang heißt es immer: „… ein kleines und sehr einfaches Programm…“, und dann fallen ähnliche Sätze wie „…ein Drei-Zeilen-Programm…“ sowie „… keine eye candies…“.

Mitten in Entwicklung, und oft gar gegen Ende heißt es dann: „… wir brauchen schon Benutzerverwaltung…“, und „… man sollte schon arabische und hebräische Texte von rechts nach links darstellen können…“, sowie „… naja auf Mac OSX muss es auch laufen…“ und nicht zu vergessen „… man soll ganz einfach das Datenbank-System auswechseln können…“ sowie „…. Daten von X ins Y migrieren können…“ aber auch „… über Internet Reports abrufen können…“ und eine Selbstverständlichkeit heißt es dann „… die Daten müssen auch in AAA, BBB, …, CSV, XML, JSON, …, ZZZ und 1000 andere Formate exportiert werden können..“ usw. usf.

Fußgängerbrücke:
Ich habe ehrlich gesagt absolut keine Ahnung, was am Anfang bei der Planung von Fußgängerbrücken verlangt und gesagt wird… aber einiges weiß ich mit Bestimmtheit:
Bei oder nach der Fertigstellung von Fußgängerbrücken heißt es nie:

  • Wir hätten gerne die Fußgängerbrücke 30 km weiter südlich!
  • Auf der Fußgängerbrücke sollten auch Radfahrer fahren können.
  • Die Fußgängerbrücke sollte schon 2 Spuren für Fahrzeuge pro Richtung haben!
  • Für jede Richtung sollte es schon einen Pannenstreifen geben!
  • Bitte baut die Fußgängerbrücke etwas breiter und baut Schienen für die Bahn dazu!
  • 1000 vollbeladene LKWs und Sattelschlepper sollten schon täglich mit 100 km/h darüber fahren können!
  • Man sollte schon pro Fahrspur eine Autoschranke haben, um Autobahnmaut zu kassieren!

Das ist keine Fußgängerbrücke mehr, sondern eine große Autobahnbrücke mit weißGottWasWeißIchAllesNoch!

Kann es sein, dass manche Kosten mit Komplexität verwechseln?

Belastung-Tests von Software und Autobahnbrücken

Software:
Man zwingt einen Mitarbeiter, eine Zeit lang mit einer Anwendung zu spielen. Ohne Ziel und Plan einfach herumklicken. Wenn die Anwendung nicht abstürzt und/oder keine Fehlermeldung kommt, dann gilt die Anwendung als „getestet“.

Autobahnbrücke:
Man hat noch nie eine Autobahnbrücke als belastbar freigegeben, nur weil ein Fußgänger oder Radfahrer darüber gegangen oder gefahren ist.

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!“.

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.“.

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.

Pareto-Prinzip (20 / 80 Regel)

Bei Pareto-Prinzip geht es vereinfacht formuliert darum:
das Verhältnis der Dinge, mit 20 % und 80 %, möglichst einfach zu beschreiben.
Dabei gibt es nur die zwei Prozentzahlen: 20 und 80 (sonst nichts).
Z. B.: 20 % Code von einer Software enthält die 80 % der Hauptfunktionen (SW Core), oder
20 % der Funktionen werden 80 % der Zeit aufgerufen, die Benutzer sehen in 80 % der Fälle 20 % der Fehler-Dialoge/-Meldungen etc. etc. usw. usf.

Bei Job-Interviews, stelle ich immer die Frage nach dem Prozentsatz meiner Tätigkeit in der Firma (welche einen Software-Entwickler für .NET/C# sucht).

Was ich erwarte: 20 % der Zeit … oder 80 % der Zeit.
Ich glaube ja auch daran, dass ein Bäcker 80 % der Zeit Brot bäckt, ein Metzger 80 % der Zeit Fleisch schneidet, ein Automechaniker 80 % der Zeit Autos repariert…

Was ich zu hören bekomme, ist jedoch:

  1. 30 % Netzwerk-Administration
  2. 30 % C# programmieren
  3. 40 % C# programmieren
  4. 60 % C++ programmieren

Naja…