Der große Softwaremurks

Wie die Informatik ansetzte, um Wissenschaft zu werden, und doch nur vor die Hunde ging.

Leser wissen, dass ich die Lage in der Softwareindustrie ziemlich schlecht bewerte.

Sicherheit, Security, eigentlich mein Hauptthema, ist heute nicht nur nicht mehr sicherzustellen (was eine zirkuläre Formulierung wäre), zu gewährleisten, man blickt eigentlich nicht mehr durch, wenn man noch einen Überblick haben will.

Ich merke das ja schon an mir selbst: Das Verhältnis von Lern- und Informationsaufwand zu tatsächlich produzierter Software wird immer schlechter, weil man immer stärker damit beschäftig ist, irgendwelche immer schneller gallopierenden Softwareupdates und neuen Moden hinterherrennen muss, weil man ja dann auch nicht bei der alten Software bleiben kann (Bugs, Sicherheitslücken, Inkompatiblitäten, aus dem Support-Zyklus raus). Vor allem wird es immer schwieriger, irgendetwas systematisch nachzulesen, sondern man googelt sich immer mehr Problemchenlösungchen (wie lautet der korrekte Diminutiv von Lösung?) zusammenzugoogelchen.

In den 90er Jahren, als ich eigentlich so an der Spitze der Internet- und Softwarekompetenz war, war das zwar nicht einfach, aber man konnte sich etwa den C-Compiler reinlernen oder Betriebssysteme wie Unix-Derivate (SunOS,…) und dann kannte man die und wusste, was man tut. Da hatte man noch die Chance, das ganze Betriebssystem zu kennen und zu verstehen. Und wenn man Software geschrieben hat, wusste man im Prinzip zu jedem Byte im kompilierten Programm, wo die Quelltextzeile dazu steht. Wir haben damals im E.I.S.S. mit unserer Sicherheits- und Kryptosoftware noch die ganze Software komplett selbst beherrscht. Die Chiffren, die Langzahlarithmetik, die Chipkartenleser, die Chipkarten – durchgehend selbst entwickelt und eigener Code – bis auf den C-Compiler, aber auch der war überschaubar. Sowas geht heute nicht mehr – wenn es noch technisch geht, dann jedenfalls nicht mehr wirtschaftlich. Es gab mal eine Zeit, da war C zwar noch primitiv, aber der Kernighan & Ritchie die Bibel. Heute muss man ständig irgendwelche neuen Standards, Normen, Releases, Features, Änderungen durchlesen, um zu wissen, wie es denn diesen Frühling so laufen soll, ohne es hinterher aber zu wissen.

Der Müllhaufen wird immer größer. Ich kann mich erinnern, dass vor 20 Jahren der C-Compiler ein statisch gelinktes (!) „Hello World“ (das klassische Minimalprogramm, das nur diese Text ausgibt, um das einfachste Beispiel eines lauffähigen Programms abzuliefern) mit etwa 3 Kilobyte hinbekam, moderne Compiler für Go oder Rust dafür aber so um die 700 Kilobyte brauchen. Weil die halt einfach jeden Scheiß mit reinbinden, weil die nicht mehr selektiv wählen können, was gebraucht wird. Damit stammt dann nicht mal mehr 1 Promille der produzierten Software von einem selbst.

Man weiß heute eigentlich nicht mehr, was da in der Software, die man produziert, eigentlich drin steckt, weil die Sprach- und Programmierumgebungen da unendlich viel Scheiß aus aller Welt über all die Abhängigkeiten reinziehen – während wir gleichzeitig darüber jammern, wie übel wir von Chinesen und Russen angegriffen würden.

Alle jubeln sie über moderne Techniken wie Virtualisierung, Container, Cloud-Computing, die auch tatsächlich große Vorteile (und Nachteile) haben, bei Licht betrachtet aber vor allem eines sind: Verzweifelte Versuche, der immer absurder werdenen Komplexität zu entkommen.

So um 2006, 2007 herum war beispielsweise Ubuntu so ein richtig bärig gutes Betriebssystem mit eigentlich allem drum und dran, äußerst robust, nicht kaputtzukriegen, zuverlässig, schnell, richtig gut. Inzwischen können sie selbst nicht mehr den Aufwand erbringen, das Ding zu pflegen und aktuell zu halten. Man versucht es mit snaps, einer neuen Art von release-unabhängigen Pakete mit der benötigten Umgebung (so auf halber Strecke zwischen einem Debian-Paket und einem Docker-Container). Aber letztlich steigt die Komplexität, weil man schon wieder ein neues Paketformat mit anderen Befehlen, anderem Verhalten, eigener Komplexität und einem sehr spezifischen, aber nur schlecht dokumentiertem und vor allem teils willkürlich gewähltem Sicherheitskonzept berücksichtigten muss, in dem dann schon wieder dies und jenes nicht mehr geht.

Log4j – Log4shell

Dazu bekommen wir immer mehr Murks. Das Kapitalsicherheitsloch log4shell war eigentlich nicht mal ein Sicherheitsloch im Sinne eines Fehlers oder Bugs, das war vorsätzlich dumm, inkompetent und unglaublich naiv programmiert, aber so gewollt. Irgendwelche Schwachsinnspriester haben Kommandos in Codezeilen ausgewertet, um von beliebigen LDAP-Server in der Welt ungeprüften Programmcode nachzuladen und auszuführen. Ich kann mir schon vorstellen, wie die dazu kamen, das stinkt nämlich so gewaltig nach DevOps, kleinen Scrum-Happen und so weiter. Man stellt erst die Kernsoftware hin und lädt dann kleine Code-Stückchen später nach. Ungeprüft, von überall.

Es gab dazu einen launigen, rustikalen, aber exzellenten und sehr, sehr gut treffenden Kommentar von Kristian Köhntopp:

Das ist so, weil in Java nichts jemals simpel ist. Java Code ist unstrukturierter trockener Staub von Codefragmenten in Klassendateien, die inert in keiner Weise miteinander interagieren. Erst mit den passenden Factories, Delegates, Generators und ClassLoaders werden sie instanziiert und zusammengesetzt. Der entstehende Haufen an Querverweisen führt dann nur zufällig irgendwann einmal tatsächlich wirksamen Code aus.

Man könnte jetzt auf die Idee kommen, eine IDE mit integrierter syntaktischer Codesuche zu verwenden, um diesen Quelltexthaufen in Form zu bringen und zu verstehen. Aber das ist vergebens: Auch mit der gesamten Codebasis und einem Index darauf kann man nicht vorhersagen, was eine gegebene Java Codebase tun wird, wenn man sie startet. Es braucht auch noch Konfigurationsdateien. Diese sind ein weiterer Haufen, Properties-Dateien, in einem vorsintflutlichen Vorläufer von YAML geschrieben: XML. […]

Das stellt sicher, dass uns niemand mehr hacken kann, weil niemand den Code mehr versteht: Wichtige, zum Verständnis der Codebasis notwendige Informationen sind versteckt in einem Verzeichnisdienst, und wir wissen nicht mal welcher. Aber wir können das noch einen Schritt weiterspielen: Der Code, der den Directory Lookup vornimmt, ist auch nicht da, nur ein Bootstrap: Event and Service Provider Packages.

Jo. Ein prächtiger Artikel, unbedingte Leseempfehlung. Und dabei gilt Java unter den Mittelkompetenten sogar noch als besonders sicher. Was aber mit den dabei gewucherten Programmiertechniken einfach nur dazu führt, dass keiner mehr Sorgen hat, weil keiner mehr weiß, was das Programm im Ganzen eigentlich macht – oder wie oder warum. Security by extended Obscurity: Wie soll ein Angreifer angreifen können, wenn noch nicht mal der Autor der Software selbst noch versteht, was da abläuft?

Blog-Artikel über 60 Jahre schlechte Softwareentwicklung

Nun hat mich jemand auf einen Blogartikel hingewiesen: 60 Jahre Software-Entwicklung: Ein Alptraum, der mit grottiger Qualität und im Chaos endet von Günter Born, der das ebenfalls treffend und zutreffend beschreibt.

In den Anfangstagen scheiterten die Entwickler oft an den notwendigen Ressourcen, die die Hardware bot. Heute haben wir unendlich viel Rechenpower, was aber durch grottige Software zunichte gemacht wird. Es wird ständig leistungsfähigere Hardware bereitgestellt, aber das Software-Zeugs läuft immer zäher. Und die Qualität der Software ist inzwischen (zumindest von mir gefühlt) unterirdisch. Warum ist das so? Ein paar Gedanken und Informationen.

Ja.

Das ist geradezu lächerlich, wie wenig Rechenleistung wir in den 80er und frühen 90er Jahren hatten. Z80 und 6502, 8-Bit-Prozessoren mit höchstens 64 kByte (!) Speicher und zwischen 1 und 4 MHz Takt. Heute haben wir 64-Bit-Maschinen mit 1 bis 4 GHz Takt bei drastisch höherer Effizienz und gerne 4, 6, 8 oder mehr Prozessorkernen, dazu locker mal 16 oder 32 GByte RAM, NVMe-SSD, Gigabit-Ethernet, und es reicht immer noch nicht.

Aber ich schaue mir als Blogger schon an, was heute von Entwicklern auf den Markt kommt und bleibe gelegentlich fassungslos zurück. Massenhafte Bugs und Ressourcen-fressende Software aller Orten. Die Tage bin ich auf Twitter über nachfolgenden Tweet gestolpert, der das Thema “Ressourcen-fressende” Software auf den Punkt bringt.

Once you understand your computer has 16 cores running at 3GHz and yet doesn't boot up in .2 nanoseconds you understand everything they have taken from you. https://t.co/8b8p45VgYL

— SwiftOnSecurity (@SwiftOnSecurity) January 25, 2022

(Seit wann haben eigentlich Schwangerschaftstests Mikroprozessoren? Zu meiner Zeit war „Doom auf dem Schwangerschaftstest“ noch, wenn da ein Strich sichtbar wurde.)

SwiftOnSecurity meint dazu: Im Jahr 2022 läuft VisiCalc auf einem Schwangerschaftstest, aber auf Computern im Büro startest Du Microsoft Excel, und der Kaffee ist schon kalt, bevor dieses Büroprogramm arbeitsbereit ist. Die Software-Entwickler haben es verkackt – O-Ton:

Wir haben den Programmierern alles gegeben, doch wir bekommen so gut wie nichts. Siliziumwunder der Metallurgie werden an den Felsen ihrer Großzügigkeit zerschmettert. Ein Programmierer zu sein bedeutet, den Diebstahl menschlicher Träume auf dem Altar der Zeit zu vollziehen.

In einer einzigen Bewegung spucken uns die Programmierer ins Gesicht und betören uns mit einer weiteren Wegwerf-Farce ihres Handwerks, die mit einem weiteren Floß aus Blei in den Ozean endet.

Ich würde weinen, aber ein Programmierer würde sicher einen Weg finden, die Zeit zu verschwenden, die meine Tränen brauchen, obwohl er in diesen Momenten mehr Rechenleistung hat als in den ganzen Jahrzehnten zuvor.

Das ist jetzt eine bitterböse Replik auf das, was Software-Entwickler den Anwendern landauf, landab vor die Füße kippen – und in einigen Fällen ist es noch geschönt.

Ja. Autos würde man sofort vom Markt nehmen, wenn sie wie Software gebaut wären. Oder zumindest war das so, bevor Autos aus Software bestanden.

Es ist fast schon ein Jahr her, dass ich bei den Kollegen von Golem auf einen Artikel Warum es so viel schlechte Software auf der Welt gibt des Softwareentwicklers und Bloggers Rajiv Prabhakar gestoßen bin (der englische Artikel ist hier zu finden). Der Autor wirft die Frage auf, warum wir so grottige Software-Qualität bekommen, und argumentiert, dass eine solche Inkompetenz in anderen Ingenieurdisziplinen niemals geduldet würde. Mit mehr Excellenz würden auch die Software-Produkte besser, so seine Schlussfolgerung, die ich aus dem Artikel herausgelesen habe.

Eine Brücke, die so fehleranfällig wie ein durchschnittliches Software-System wäre, würde niemals zum Betrieb freigegeben werden. Die Theorie dieses Autors: Es gibt zu viele Entwickler, die faktisch inkompetent sind, und genau so ist die Qualität der Produkte. Da ich sowohl eine Ausbildung als Ingenieur habe, als auch eine Menge Zeit in Informatik-Vorlesungen investiert habe, kann ich das nachvollziehen und unterschreiben.

Das ist wahr.

Aber auch nur die halbe Wahrheit.

Der Kunde will eben auch immer schneller immer mehr blöde Gimmicks, und die Firmenleitung will schnell, viel, billig. Immer mehr Schnickschnack, weil man irgendwas braucht, was das Konkurrenzprodukt nicht hat, sogar dann, wenn das Konkurrenzprodukt die letzte Version der eigenen Software ist und man den Leuten neue Software andrehen will.

Die gesamte Branche ist geprägt von der US-Kultur, die keine berufliche Ausbildung, wie im deutschen Handwerk oder im Ingenieurbereich kennt. Da ich beruflich über ein Jahrzehnt in der Industrie an der Schnittstelle zwischen Ingenieuren und Informatikern tätig war, sind mir auch die Unterschiede in der Denkweise aufgefallen.

Die Ingenieure hielten sich streng an Regeln, Normen und an das, was auf ihrem Gebiet als Stand der Technik definiert war. Die Informatiker konnten zwar – wenn sie was taugten – in Algorithmen denken und beherrschten die jeweiligen Software-Entwicklungsumgebungen. Aber es gab – bis auf wenige Ausnahmen – keinen Plan, wie die Welt da draußen, die durch Software abgebildet werden sollte, so tickt. Entsprechend häufig wurden IT-Projekte an die Wand gefahren. Der Glaube: Wir brauchen nur ein geeignetes Tool und genügend Zeit und Geld, dann wird das schon, ließ Projekte regelmäßig gegen die Wand fahren – oft auch, weil die Prozesse, die eigentlich durch die Software abgebildet oder die Anforderungen der Nutzer, die abgedeckt werden mussten, nicht verstanden wurden.

Ja.

Er beschreibt das zwar schon etwas, naja, ich würde nicht sagen laienhaft, mehr so aus Außensicht, weil man halt doch merkt, dass er kein Informatiker ist, und die Prozesse nicht so richtig verstanden hat. Aber seine Bewertung ist richtig. Denn wenn man die Prozesse verstanden hat, drückt man sich und seine Aussage zwar schon anders aus, aber zu einer besseren Bewertung kommt man dann auch nicht.

Und ein Problem hat er auch nicht erfasst. Es geht nicht nur darum, Leute ohne Berufsausbildung einzustellen. Das wurde auch in den USA durchaus gefordert.

Aber wir haben durch schlechte Organisation in der rapide angestiegenen IT schlicht und einfach mehr Hirnbedarf, als Schulen und Universitäten an einsatzfähiger Hirnmasse produzieren.

Wir sind als Staat, als Gesellschaft einfach zu dämlich, um die Aufgabe zu lösen. Weil wir das Prinzip der Gleichheit verfolgen und deshalb alle auf das Niveau der am wenigsten geistig leistungsfähigen runterbremsen.

Oder anders gesagt: Wir sind der Staat Feminismus+Merkel: Durchlabern.

Hätte man die Aufgabe und Problemstellung verstanden, hätte man in den 90er Jahren angefangen, die Schul- und Universitätsausbildung knallhart hochzutreiben und eine technointellektuelle Elite zu bauen, die gut in Mathe, abstraktem Denkem, Algorithmen und so weiter ist. Ich hätte ja durchaus auch Frauenförderung betrieben, aber halt ganz anders: Ich wäre in die Gymnasien an die Unter- und Mittelstufe gegangen, und hätte den Mädels gesagt: Hört zu, wenn Ihr mal einen ordentlich Job mit ordentlicher Bezahlung haben wollt, müsst Ihr was können und bieten, und das geht nur über Technik, Mathematik, Physik, Informatik. Also setzt Euch verdammt nochmal auf Euren Hintern und kümmert Euch um Mathematik und so’n Zeug, anstatt Abitur in Sport und Geschichte zu machen und Geisteswissenschaften zu studieren.

Man hat es aber umgekehrt gemacht:

Man hat die Frauen feministisch blöd gehalten und ihnen stattdessen so geistige Rollstuhlrampen für Doofe gebaut. Frauenquoten und Quereinsteigertum. Statt Frauen, die man einstellen will, bekommt man Frauen, die man einstellen muss. Ich habe genug erlebt, meist an der Universität, manchmal in der Industrie, die da auf ihrem Quotenposten

Es wäre jetzt aber schon verfehlt, das jetzt nur den Frauen anzulasten, der Großteil der schlechten Software wurde eindeutig von Männern geschrieben.

Aber vieles hat auch damit zu tun, dass die geisteswissensschaftliche Verblödungswucherung auch die Informatik erwischt hat. Was ich in und im Nachgang zu meinem Promotionsstreit an brachial dummen Leuten und unglaublich dämlichen und schlechten Dissertationen, Arbeiten, Artikeln, Vorlesungen, Äußerungen gesehen habe, ist mit Worten eigentlich nicht mehr zu beschreiben. Was für unfähige und verlogene Leute da in den Professuren sitzen, und das dann eben auch wieder über Quotenfrauen, die inzwischen einfach alles zur Gender-Vorlesung runterverblöden. Dazu gehört aber eben auch die massive Korruption, massenhaft inkompetente Leute einzustellen. Ich habe in meinem Promotionsstreit mit jeder Menge Prüfern und Gutachtern zu tun gehabt, die selbst nie Informatik studiert haben und die Sachkunde nicht hatten, die einfach zum Informatikprofessor ernannt wurden (oder sich selbst zum Kryptologen ernannt haben).

Und diese Verblödung, die im Kindergarten schon anfängt und sich auch durch die ganze Uni zieht, hinterlässt ihre Spuren. Ich habe die letzten Jahre häufig eine Schulung für Programmier-/Scrum-Teams im Bereich DevOps-Zugang gehalten, über Jahre nahezu unverändert immer denselben Inhalt, und damit einen Vergleichsmaßstab. Die Befähigung der Leute ging über die Zeit immer stärker zurück. Vor vielen Jahren musste ich den Leuten kaum etwas erklären. Ich habe gesagt, Ihr müsst das und das, und die Leute haben verstanden, was ich von ihnen will. Ja, kennen wir, fertig. Im Laufe der Zeit ist der Zeitaufwand für so eine Schulung von anfangs 30 Minuten immer stärker auf deutlich über 60 Minuten gestiegen.

Immer öfter hatten die Leute nur noch rudimentäres Wissen darüber, was eigentlich eine ssh ist und macht. Immer mehr musste ich erklären. Mal wussten sie nicht, was agent forwarding ist. Dann kamen welche, die nicht wussten, was ein Public-Key-Schlüssel ist. Dann kamen welche, die überhaupt nicht wussten, was eine ssh ist und was man damit macht. Und dann welche, die sich schwer damit taten, zu verstehen, was eine TCP-Verbindung ist. Immer mehr, immer ausführlicher musste ich das erklären.

Ich hatte über die Jahre hinweg eine Kontrollfrage. Genauer gesagt, nicht mal eine Frage, sondern einfach eine Aussage, die eigentlich nicht möglich ist und Widerspruch erzeugen müsste. Um zu sehen, ob die Leute wach sind und mitdenken. Nachdem ich also erst erklärt habe (was man eigentlich schon wissen musste, oder wovon viele vorgaben, es zu wissen), wie das mit ssh und Verschlüsselung und so funktioniert, hatte ich ein Schema gezeigt. Man logt sich per ssh auf Server A, von dort auf Server B, und von da schließlich auf Server C ein. Verstanden? Ja! Gut!

Nun muss ich Euch aus arbeitsrechtlichen Gründen darüber belehren, dass auch Sicherheitsgründen zwischen Server B und Server C noch ein System D hängt, das alle Shellbefehle mitprotokolliert, die Ihr eingebt.

Vor vielen Jahren kam da noch Widerspruch. Geht doch gar nicht, wie soll D das mitprotokollieren können, ist doch verschlüsselt! (Gut aufgepasst! Lösung: D fängt die Verbindung ab, hat eine Kopie des Schlüssels von C und gibt sich gegeüber B damit als C aus, und reicht durch.)

Dann kamen viele, die es nicht merkten, selbst wenn ich dazu mit der Verkehrsampel winkte. Ich: Verstanden? Sie: Ja! Ich: Nein, habt Ihr nicht. Die aber dann merkten, dass das so nicht passen kann, wenn ich sie daran erinnerte, dass die Verbindung verschlüsselt ist und da was nicht stimmen kann. Die aber dann auch nur vorgaben, es verstanden zu haben, wenn ich sagte, dass System D eine Kopie des Schlüssels von C hat und sich deshalb als C ausgeben kann. Ich habe mir einmal erlaubt, an der Stelle völligen Blödsinn darüber zu erzählen, wer welchen Schlüssel hat, komplett falsch, und es hat auch keiner gemerkt.

Und dann kamen die, die keinerlei Widerspruch darin sahen, dass die Verbindung verschlüsselt ist und ein System daran hängt, das mitprotokolliert. Die nicht verstanden, dass wenn eine Verbindung verschlüsselt ist, man da eben nicht mitlesen kann. Entweder Augen auf unendlich, oder so Widerspruch, das könne ja nicht stimmen, weil doch der Staat auch überall mithört, man also Verschlüsselungen offensichtlich abhören kann. Die Frage, wozu man dann überhaupt verschlüsselt und was dann der Grund dafür und der Vorteil daran wäre, konnten sie mir auch nicht beantworten.

Und dann kam eben noch die Generation Black Lives Matter und Frauenquote. Und da war ich dann eben auch der Überzeugung, dass ich da einfach falsch bin und nicht mehr reinpasse.

Hintergrund war eben, dass man zunehmend Leute bekommt, die zwar an der Universität Informatik studiert haben, aber eigentlich nichts können. Weil schon die Dozenten nichts konnten. Und dann die, die eigentlich irgendwas ganz anderes gelernt haben, oft Physiker oder Geisteswissenschaftler, manchmal auch irgendwas aus der Chemie, die halt da unterkommen wollen, wo es noch Jobs gibt.

Die IT wurde dann auch irgendwann zum Auffanglager und Ersatzarbeitgeber für den ganzen Akademisierungsmüll. Wir produzieren lauter Absolventen, die dann mit 30 oder 35 totakademisiert und zu nichts mehr zu gebrauchen sind, (aber keine Erdbeeren pflücken wollen, um auf einen früheren Artikel anzuspielen), und dann politisch und gesellschaftlich in die IT gedrückt werden, weil die doch „Fachkräftemangel“ hat.

Dazu kommt dann das dumme Geschwätz der Soziologen, Kulturwissenschaftler, Philosophen, die das ganze Wissenschaftszeugs nur als soziales Ding mit spezifischem Gruppenverhalten darstellen, in dem es nichts zu können gibt, sondern nur das gruppentypische Verhalten nachzuahmen (oder umgekehrt der Gruppe einzuhämmern hat, dass sie ihre Sexismen aufgeben und „Quereinsteiger“ einfach akzeptieren solle), dass IT so eine Art Spiel oder Gruppentanz ist, bei dem man alle mitspielen oder mittanzen lassen müsse. So wie Soziologie oder Philosophie eben, wo auch jeder nach Belieben und Rangordnung mitschwätzen kann, was ihm gerade einfällt.

Dann kommt noch so eine Trulla-Regierung wie Merkel dazu, die ohnehin nichts kapiert und alles irgendwie egalisiert, ignoriert, planiert, und sich auch noch gut darin vorkommt, den Leuten „Fachkräfte“ zu schicken, um die sie ja gebeten hatten.

Und so stehen wir nun vor einem riesigen Haufen irreparablen Softwaremülls, der immer weiter wuchert wie ein außerirdischer Monsterschimmelpilz.

Und dann haben wir Politiker, die zu einem wesentlichen Teil an dem Mist schuld sind, und die erklären, dass Deutschland in ein paar Jahren an die Spitze soll. Wovon auch immer. Mal mit Internet of Things. Dann mit Blockchain. Oder mit KI. Weil man an die Spitze kommt, indem man hochaktuelle Begriffe laut ruft, die man in der Zeitung gelesen hat. Weil man glaubt, dass IT ein Sozialhaufen von Nerds ist, die sich komisch benehmen, und von morgens bis abends das Modewort X rufen.

Weil man glaubt, viel hilft viel.

Und so wird unsere Software nicht besser, sondern einfach nur immer mehr, immer komplexer, immer unverständlicher.

Spätestens mit Log4j war der Zustand erreicht, an dem man nicht versehentlich als Bug, sondern gewollt, Software gebaut hatte, von der wirklich gar niemand mehr verstand, was sie eigentlich tat.

Und manche finden das dann auch noch gut und nennen das dann „KI“.