Software treibt Menschen in den Wahnsinn

Ich wollte diesen Gedanken gerade unter dem neuesten "Wir wechseln von Tech/Architektur X zu Y"-Beitrag auf der HN-Startseite posten, aber jetzt finde ich, er gehört hierher.

Ich habe mich kürzlich mit einem Freund darüber unterhalten, wie wir früher mit so wenigen Entwicklern so viel mehr geschafft haben: Vor 20 Jahren entwickelten wir geschäftskritische Echtzeit-Software (Trading-Systeme) in C++ mit einem Team von ein paar Dutzend Entwicklern. Das Kernteam für den Trading-Kernel bestand aus vier Personen. Ein internes verteiltes Prozess-Orchestrierungstool (sowohl Frontend als auch Backend in C++ geschrieben) waren zwei Leute. Ich selbst habe es einmal geschafft, ein komplettes Post-Trade-Risikomanagementsystem für Futures-Kontrakte in ein paar Monaten allein zu entwickeln. Heute sehe ich Teams von 60-80 Leuten, die an Web- und Mobile-Anwendungen arbeiten, bei denen die überwiegende Mehrheit der Operationen CRUD ist, mit etwas Transaktions-/Queue-Komplexität an den Rändern.

Ich denke, der Unterschied ist der Technologie-Wandel. Damals waren die wenigen Abhängigkeiten, die wir hatten – sei es Laufzeitbibliotheken oder Entwicklungswerkzeuge – stabil: die Standardbibliothek, der Compiler, Unix-Befehle und Bash-Skripte sowie einige interne Bibliotheken. Ein Großteil unserer Zeit und Konzentration floss in die Entwicklung der richtigen Algorithmen und Datenstrukturen, das Programmieren kam an zweiter Stelle. Sehr wenig Zeit wurde für die Auswahl, Konfiguration, Aktualisierung, Neuarchitektur oder den Austausch von Tech-Stacks und Tools aufgewendet.

OP hat praktisch die Wirkung des Egos durch Software beobachtet, ist aber noch nicht ganz zu der Fähigkeit gelangt, sie zu quantifizieren.

Lies noch einmal alles durch und wende jedes gegebene Beispiel durch diese Linse an.

Es ist möglich, dass wir in einer Branche sind, die diesen Teil der menschlichen Natur übermäßig zum Ausdruck bringt, aber ich bin mir ziemlich sicher, dass er überall auftaucht, wenn auch durch andere Anekdoten. Wende eine reduktionistische Zen-buddhistische Sicht auf deine berufliche Kreativität an, und all das verschwindet.

Bob will ein Subsystem refaktorieren, weil es ihn zum Helden macht, und wenn er es dem Management richtig verkauft, werden der technische Wert und das tatsächlich erreichte Erfolgsniveau irrelevant sein. Alice beschließt, einige offensichtliche Bedenken zu äußern und sich dann zurückzulehnen und die Show zu beobachten. Jane beschließt, im Stand-up die Hände hochzuwerfen und alle emotional davon zu überzeugen, dass der Himmel einstürzen wird. Sei wie Alice und bewahre deinen Verstand.

Meine Beobachtung ist einfach die, dass Tech-Führungskräfte Belohnungen vom Markt für die Eroberung einer abstrakten Darstellung einer Facette einer Domäne mit der Eroberung der Domäne selbst verwechseln. Dann werden sie größenwahnsinnig.

Hast du Gewerbeimmobilien erobert und die Zukunft der Arbeit und Gesellschaft eingeläutet, oder hast du eine praktische Terminplanungs-App gebaut?

Hattest du eine nette Idee für eine Online-Community oder hast du die menschliche Verbindung revolutioniert?

Erinnert mich an diesen Beitrag von 2014 "Programming Sucks" [0], der einige ähnliche Probleme anspricht, nämlich die Loslösung von der Realität in einem Mikrokosmos, der immer "besser sein sollte", als er ist.

> Alle Programmiererteams werden von und aus verrückten Menschen zusammengestellt [...]

> Die destruktive Wirkung auf das Gehirn zeigt sich an den Programmiersprachen, die Menschen schreiben. [...]

> Alle Programmierer zwingen ihre Gehirne, Dinge zu tun, für die Gehirne nie gemacht waren, in einer Situation, die sie nie verbessern können, zehn bis fünfzehn Stunden am Tag, fünf bis sieben Tage die Woche, und jeder Einzelne von ihnen wird langsam wahnsinnig.

[0] https://www.stilldrinking.org/programming-sucks

Ist es die Software, die diese Wirkung hat, oder das Management über Softwareprodukte? Ich sehe nicht viele akademische oder Hobby-Softwareprojekte, die ständig nach Lust und Laune ändern, was für sie wichtig ist. In der Softwareindustrie sieht man das allerdings ständig.

Es ist nicht die Software; es ist die Tatsache, dass die meisten Manager/Administratoren keine Softwareentwickler sind (obwohl sie vielleicht etwas Programmierfähigkeit haben). Sie stehen also in derselben Beziehung zu ihrem Entwicklungsteam wie Kunden, die sich bei einem Hersteller über die Funktionen eines physischen Produkts beschweren und sagen: "Es sollte dies oder das tun, das ist eine einfache Änderung" (weil es einfach ist, sich vorzustellen, es zu haben, wenn man die Mühsal der Implementierung überspringt).

Natürlich ist die Bitte manchmal gerechtfertigt und behebt einen Mangel der ursprünglichen Spezifikation, sei es durch mangelnden Ehrgeiz oder übermäßigen Ehrgeiz, der einen Frachtcontainer an einen Rasenmähermotor gehängt hat. Aber der größte Teil des im Artikel beschriebenen Konflikts entspringt einer Kombination aus der Vorstellung der Vorteile einer Änderung und der unausgesprochenen Annahme, dass die Implementierung nur eine Frage des Drückens ein paar weiterer Knöpfe ist.

Ich liebe diese Formulierung. Ich habe viele Ideen, warum das stimmt, aber die beste (meiner Meinung nach) einfache Erklärung, die mir eingefallen ist, ist:

1. Ein Großteil der Softwarekonstruktion ist eine Art Mathematik. In der Mathematik schreibt man Beweise, die sagen, warum X wahr ist. In der Software schreibt man Code, der garantiert, dass X wahr sein wird (z. B. "das Backend ging davon aus, dass eine Benutzer-ID immer verfügbar war, aber jetzt, wo wir Service-Accounts haben, müssen wir den Zugriffskontrollcode ändern, damit immer noch eine sinnvolle Ansicht zurückgegeben wird")

2. Mathematik ist schwer, und der größte Teil der Arbeit ist unsichtbares Denken. Wenn man einen Mathematiker nach einer Schätzung fragt, wann die Riemannsche Vermutung bewiesen sein wird, würde er einen auslachen. Unsere Probleme sind im Allgemeinen einfacher, aber sie können trotzdem schwer sein. Und wie in der Mathematik sind sie manchmal viel schwerer, als man erwartet (z. B. Fermats letzter Satz. "Warum war es so schwer? Hast du mit Fermat gesprochen? Er ist gegangen? Aber er sagte, es wäre einfach!")