Wir machen Software kaputt

• Wir machen Software kaputt, indem wir Komplexität nicht mehr berücksichtigen, wenn wir Funktionen hinzufügen oder bestimmte Teile optimieren
• Wir machen Software kaputt mit komplexen Build-Systemen
• Wir machen Software kaputt, indem wir mit absurden Abhängigkeitsketten alles aufblähen und angreifbar machen
• Wir machen Software kaputt, indem wir neuen Programmierern sagen: "Don’t reinvent the wheel!". Dabei ist es gerade das Neuerfinden des Rads, durch das man lernt, wie Dinge funktionieren, und der erste Schritt zu einem neuen, anderen Rad
• Wir machen Software kaputt, indem wir die Abwärtskompatibilität von APIs nicht mehr berücksichtigen
• Wir machen Software kaputt, indem wir dazu drängen, Dinge neu zu schreiben, die bereits funktionieren
• Wir machen Software kaputt, indem wir auf jede neue Sprache, jedes neue Paradigma und jedes neue Framework aufspringen
• Wir machen Software kaputt, indem wir immer unterschätzen, wie schwierig es ist, bestehende komplexe Bibliotheken zu handhaben, verglichen mit einer Eigenimplementierung
• Wir machen Software kaputt, indem wir davon ausgehen, dass der De-facto-Standard für XYZ immer besser ist als etwas, das wir direkt für unseren konkreten Anwendungsfall implementieren könnten
• Wir machen Software kaputt, indem wir behaupten, Code-Kommentare seien nutzlos
• Wir machen Software kaputt, indem wir Software fälschlich nur als reine Ingenieursdisziplin verstehen
• Wir machen Software kaputt, indem wir Systeme bauen, die sich nicht mehr reduzieren lassen: In jedem System sollte Einfaches auch einfach zu erreichen sein
• Wir machen Software kaputt, indem wir Code so schnell wie möglich herauspressen wollen, statt zu versuchen, ihn so gut wie möglich zu entwerfen
• Wir machen Software kaputt, und was übrig bleibt, wird keine Freude am Hacken mehr vermitteln

[dohyun682]

Das Rad neu erfinden <-> das neu erfinden, was man ohnehin schon schreibt

Sind diese beiden nicht völlig gegensätzliche Konzepte?

[roxie]

Der Kommentar-Boom kommt.

[tujuc]

Das trifft es wirklich, haha. Jedes Mal, wenn neue Junioren dazukommen ... überlege ich, wie ich es ihnen erklären soll. Das scheint eine gute Methode zu sein..

[ilikeall]

Bitte hört auf, darauf herumzuhacken ;_;

[bus710]

....Ich halte einfach still...

[laeyoung]

Es gibt vieles, das sich mit den von Han Feizi genannten „zehn Anzeichen für den Untergang eines Staates“ zu überschneiden scheint.

[GN⁺]

Hacker-News-Kommentare

• Erinnert an einen Vortrag von Jonathan Blow. Software verfällt wie alles andere auch, wenn man sie nicht pflegt

  • Softwaretechnik scheint sich oberflächlich weiterzuentwickeln, befindet sich tatsächlich aber im Niedergang
  • Hardware-Verbesserungen und Machine Learning erzeugen die Illusion von Fortschritt, während die grundlegende Robustheit und Zuverlässigkeit von Software schlechter werden
  • Moderne Softwareentwicklung ist unnötig komplex geworden und macht selbst einfache Aufgaben schwierig
  • Diese Komplexität verringert die Produktivität von Programmierern und behindert die Weitergabe von Wissen zwischen Generationen
  • Die Gesellschaft akzeptiert fehlerhafte und unzuverlässige Software als normal
  • Wenn Softwaresysteme nicht auf allen Ebenen vereinfacht werden, vom Betriebssystem bis zu den Entwicklungswerkzeugen, droht der Zivilisation ein technischer Rückschritt, der historischen Zusammenbrüchen ähnelt

• Erinnert an Dieter Rams’ „10 Prinzipien guten Designs“

  • Gutes Design ist innovativ
  • Gutes Design macht ein Produkt brauchbar
  • Gutes Design ist ästhetisch
  • Gutes Design macht ein Produkt verständlich
  • Gutes Design ist unaufdringlich
  • Gutes Design ist ehrlich
  • Gutes Design ist langlebig
  • Gutes Design ist konsequent bis ins letzte Detail
  • Gutes Design ist umweltfreundlich
  • Gutes Design ist so wenig Design wie möglich

• Teilt Erfahrungen aus der Arbeit in einem Unternehmen in den 2000er-Jahren

  • Führte Aufgaben mit Dutzenden von Computern aus, baute einen Serverraum auf und ein SAN zur Speicherung von 3 TB Daten
  • Koordinierte Abläufe zwischen Computern mit einem selbst entwickelten VB6-Task-Scheduler, der Object Rexx-Skripte ausführte
  • Nutzte interne Load Balancer, Webserver, Mailserver und FTP-Server zum Senden und Empfangen von Dateien sowie eigene Software
  • Heute lässt sich die gesamte Konfiguration innerhalb einer Woche mit yaml-Dateien und Cloud-Diensten reproduzieren
  • Die Serverarchitektur wurde „abstrahiert“
  • Kritik an Abwärtskompatibilität, die als eines der Probleme von Windows genannt wird
  • Apple brach die Abwärtskompatibilität, wechselte über fünf Prozessoren hinweg und entfernte die Kompatibilität für 32-Bit-Code auf ARM-Chips

• Es gibt viele gegensätzliche Meinungen

  • Man sollte Abwärtskompatibilität beibehalten und dabei Komplexität vermeiden
  • Man sollte riesige Abhängigkeitsbäume vermeiden und das Rad selbst neu erfinden
  • Die einzige Möglichkeit, alle Anforderungen zu erfüllen, besteht darin, dass nicht jeder Code schreibt
  • Man wünscht sich das vielleicht einmal am Tag, ist aber nicht stolz darauf

• Teilt Erfahrungen aus dem ersten Job

  • Schrieb Software in C, weil es realistisch gesehen die einzige Sprache war, in der sich kommerzielle Software schreiben ließ
  • Nur eine Person konnte Builds erstellen, nutzte ein kommerzielles Build-Tool und war zugleich die einzige Person, die dieses Tool bedienen konnte
  • Ein Build dauerte mehrere Stunden
  • Wir dachten, wir machen das gut

• Meinung dazu, warum wir Software kaputtmachen

  • Wir machen Software kaputt, indem wir immer davon ausgehen, dass der De-facto-Standard von XYZ besser ist als etwas auf uns Zugeschnittenes
  • Ein allgemeiner Ansatz lässt sich leicht in eine oberflächliche Lösung für viele Probleme verwandeln
  • Techniker mögen diesen Ansatz, insbesondere weil sie häufig den Job wechseln und davon einige mitbringen
  • Maßgeschneiderte Lösungen leisten jedoch oft deutlich mehr als generische

• Jede Aussage ist ein Tauschgeschäft

  • In jedem Fall opfert man etwas, um etwas anderes zu gewinnen
  • Manchmal ist es sinnvoll, das Rad nicht neu zu erfinden
  • Manchmal muss man das Rad neu erfinden, um zu lernen
  • Insgesamt erschaffen wir mehr, als wir zerstören
  • Ich sehe keinen Grund, eine negative Haltung einzunehmen

• Bewundert antirez, hält diesen Beitrag aber für voller kurzer, gut klingender Aussagen, die einer Diskussion nicht standhalten

  • Zum Beispiel: Anfänger sollten das Rad nicht neu erfinden
  • Sie sollten die im gegebenen Kontext verfügbaren Werkzeuge nutzen
  • Wenn sie experimentieren wollen, sollten sie ihren eigenen Compiler schreiben
  • Aber sie sollten ihn nicht in Produktion einsetzen
  • Rückwärtskompatibilität von APIs ist in den meisten Fällen eine Geschäftsentscheidung
  • Jeden Satz mit „Wir zerstören Software“ zu beginnen, hilft nicht
  • Es klingt viel düsterer, als es tatsächlich ist

• Meinung zu Komplexitäts-/Abhängigkeitsgraphen

  • Der Komplexitäts-/Abhängigkeitsgraph einer zufälligen Anwendung ist völlig absurd
  • Firmware und OS sind darin nicht enthalten, aber es kommt dem schon ziemlich nahe
  • Das Problem transitiver Abhängigkeiten muss gelöst werden
  • Betrachtet das OS (Win32 API, Linux-Syscalls) als die einzige harte Abhängigkeit von allem, was in C geschrieben ist
  • Wenn man zu Java/Python wechselt, kann man diese Schicht nicht kontrollieren
  • Es ist nötig, ein paar hundert Zeilen Code für eine konkrete Situation zu schreiben, statt von jeder Bibliothek abhängig zu sein
  • Das erhöht zwar den Wartungsaufwand, aber Abhängigkeiten müssen ebenfalls gepflegt werden
  • Sie können schlechte APIs haben, willkürlich die Kompatibilität brechen, aufgegeben werden oder zu Malware werden
  • Die persönliche Obergrenze für nützliche Projekte liegt bei 5–10 KLOC in Java/JS/Python
  • Das lässt sich in wenigen Stunden prüfen und Jahre später leicht ändern

• Faktoren, die Software kaputtmachen

  • Leetcode-Interviews, lebenslaufgetriebene Entwicklung, häufige Jobwechsel, Wachstumsinvestitions-Betrug, Metrik-Spielchen, Jagd auf Beförderungen, Sprint-Theater, Aufschneiderei auf jeder Ebene des Organigramms, Gleichgültigkeit der Branche