Die Softwareentwicklung ist entgleist

Gastautor: Lerby

In der Softwareentwicklung geht immer mehr schief. Ich quäle mich beim (Noch) Arbeitgeber seit 2018 mit zusammengeschusterten Komponenten ab, deren Anfänge auf 2013 zurückgehen. Als ich dort anfing, verstand ich trotz meiner 24 Jahre Erfahrung 90 % der Unterhaltungen um mich herum nicht. Die Worte schon, aber nicht, warum die gleichen Techthemen immer wieder hochkamen. Wie konnte das sein, 5 Jahre nach Entstehung des Projekts? Und warum sprach niemand über die Ausrichtung des Projekts, die Zielsetzung der Firma, die Prioritäten? Hier eine Aufzählung und ein Erklärungsversuch, was schiefging. Kontext: Ich zog 2011-2014 ein ähnliches Projekt durch - aber mit 12 Leuten in 3 Jahren. Jetzt hab ich fast 40 Leute, aber alles Schneckentempo.

Open Source über alles

Seit 2007 höre ich, dass Open Source moralisch über den Bezahl Tools und -Software steht. Wie die Pudel bei Nutten - wer zahlt denn für sowas??? Hauptsache umsonst herunterladen und es denen mal so richtig zeigen! Das ist nicht nur falsch, sondern eine mutwillige Arbeitsverweigerung. Man benutzt die besten Tools, die man finden kann, quantifiziert und vergleicht die Erwartungswerte von Pro und Contra jedes Ansatzes, und nimmt die Lösung mit den grössten Erfolgschancen. Entwickler sind teuer, da sind die Kosten der Entwicklungsumgebung fast egal. Eine solche Analyse kann man aber nur machen, wenn man sich in beiden Welten auskennt. Wer aus Ideologie oder Moral immer die Open Source nimmt, hat keine Chance auf grösstmöglichen Erfolg.

Python für alles

Python wird immer mehr zum Allheilmittel und hat Excel als den Katastrophenherd im Geschäftsleben schlechthin abgelöst. Warum? Mit Python kann man schnell was zusammenstricken, schnell was herunterladen, und fertig ist der Prototyp. Das ging ja schnell, Donnerwetter! Das geht aber nur, weil Python bewusst einfach gestrickt ist. Es gibt z.B. so gut wie keinen Einfluss auf Verbrauch von Speicherkapazität. Das zeigt sich am schlimmsten, wenn ein Pythonprozess die nächste interne willkürliche Grenze überschreitet, und auf einmal braucht das Ding 100 GB statt 4 GB an Speicher. Dann bricht einem schnell alles zusammen, ohne Grund, ohne Kontext. Und wie soll man den Krieg der Skalierung zwischen Speicher und CPU gewinnen, wenn sich der Speicher wie ein epileptischer Presslufthammer verhält? Dann ist die "Rettung" horizontaler Skalierung, also mehr Hardware, anstatt das Problem anzugehen. Und weil man so viele Hobel braucht, um einfachste Dinge am Laufen zu halten, geht das sofort los mit DevOps und wie man dynamisch mehr Hobel anschliesst usw. Nein - nicht weil sich das Geschäft vermehrfacht hat, sondern weil die Python Prozesse um sich schlagen!

Dazu kommen zwei kulturelle Probleme. (1) Es sind Prototypler am Werk, die schnellen Erfolg wollen, und denen egal ist, wie das Ding in 2 oder 5 Jahren unterwegs ist. Dieser Ansatz zieht die falschen Leute an. (2) Python lädt zum Herunterladen irgendwelcher Komponenten ein, um zum schnellen Erfolg zu kommen, aber man bekommt damit 4 Probleme. (a) Man stellt sich auf einen Krieg ein mit Komponenten, wo irgendwelche Hippies in Kalifornien entscheiden, welche Funktionen es mit welchen Schnittstellen in die nächste Version schaffen. Und wenn man das Upgrade vertändelt, wird der nächste schwerer und der danach fast unmöglich. Warum soll ich soviel Kontrolle über mein System abgeben? (b) Die vergeudete Zeit. Meine Mannschaft mit 40 Leuten verprasst 30 % der Zyklen mit Upgrades. Strahlkotz. Man bringt per einfaches Herunterladen hunderte von Tausend Zeilen Quellcode in seine Infrastruktur, ohne die jemals benutzt oder getestet zu haben. Das ist ein Albtraum für die Cyber Security (d) Man erschafft eine Kultur von DevOps, wie man überhaupt seine Scheiss Plattform jemals nochmal zum Laufen bekommt, mit all diesen Libraries. Ich habe config files mit über 1000 Zeilen gesehen, um Puppet oder Jenkins davon zu überzeugen, nochmal was zum Laufen zu bekommen. Das ist doch Irrsinn.

DevOps, Container - warum?

Nachgehakt, Thema DevOps und das Verwalten dutzender Libraries, teilweise mit verschiedenen Versionen. Hab das leider schon vielmal erlebt. Statt Software zu schreiben, werden Libraries heruntergeladen, für den schnellen Erfolg. Dann entdeckt man 6 Monate später eine neue geile Funktion, aber halt nur in der letzten Version. Aber die alte lässt sich nicht einfach erneuern, weil ja die paar Funktionen, die man benutzt hat, in der neuen Version so nicht mehr gehen. Also nimmt man einen Container, und stülpt den über eine bestimmte Mixtur von Versionen von Libraries darüber und erklärt das als eine Einheit. Dann geht man zur nächsten Insel und macht das Gleiche. Und ehe man es mitkriegt, braucht man 3 Leute, die einem nur diese Container verwalten. Und all das, weil man keine einfache Software geschrieben hat, mit sauberen und unabhängigen Schnittstellen, die man fast unabhängig voneinander verändern kann. Alles klebt aneinander, das ist tight coupling, das ist CORBA in seiner schlimmsten Form.

Wie kam es dazu?

Ich bin jetzt mal gemein und zeige mit meinem Finger auf die Bequemlichkeit und den Gottkomplex der Softwareentwickler hin. Anstatt die harte Arbeit zu machen, die durch das Verstehen der geschäftlichen Aufgabe entstehen und anstatt der Projektion dieses Verständnis auf einen technischen Kontext - denn das ist ja ungemütlich, arbeiten sich die Softwarefuzzies lieber an Spielzeugen ab. Noch ein Case Tool. Noch eine silberne Kugel, mit der man 50 Jahre Erfahrung einfach ersetzen kann - ja von Wegen. Aber Hauptsache, man hat die Auseinandersetzung mit dem eigentlichen Problem verschoben, und man kann die Geschäftsbereiche mit eindrucksvollem Jargon beeindrucken. Und dazu kommt der Gottkomplex. Anstatt sich in das Geschäft reinzuversetzen, hetzt man herum, und stellt dar, dass die nicht Techniker zu blöd sind, zu erklären, was sie wollen. Nein - denn die wissen nicht, was einfach oder was schwer ist zu bauen, und können deswegen nicht präzise formulieren, was genau wir unbedingt brauchen bzw. wünschen oder gerne hätten. Da muss die IT mitgehen und viel früher kommunizieren. Die Programmierung und Umsetzung ist nur ein kleines Teil des Problems. Aber dieses kleine Teil wird aufgebauscht, weil sich die IT nicht mit den eigentlichen Problemen auseinandersetzen will, und stattdessen ein kompliziertes Frankensteinmonster nach dem anderen erfindet, um sich zu beschäftigen. Ich finde die Sparte immer mehr zum Kotzen und freue mich auf meine nächste Aufgabe, wo ich mal zur Abwechslung selber was aufbauen kann, als die Trümmerhalden der feuchten Träume der Toolsfetischisten aufzuräumen.

Diskutiere über diesen Artikel und teile Deine Erfahrungen mit anderen Lesern!

Beachte bitte die Kommentarregeln!

Wenn Du selbst spannende Themen oder interessante Erfahrungen hast, dann schreib doch einen Gastartikel darüber, natürlich völlig anonym. Unser Gastartikelportal mit weiteren Informationen findest Du hier.

Hast Du auf dieser Seite einen Fehler entdeckt? Auf unserer Fehlerhinweisseite kannst Du uns darauf aufmerksam machen und eine Korrektur vorschlagen.