Mein softwaretechnischer Polarstern

Prioritäten bei der Softwareentwicklung

1. Software sollte für Endnutzer nützlich sein und darauf abzielen, „Software, die man lieben kann“ zu werden.
2. Software muss korrekt (correct) sein. Fehlfunktionierende Software verringert den Nutzen, den Nutzer daraus ziehen können.
3. Software sollte wartbar und effizient sein. Das ist der Maßstab, um Verschwendung von menschlichen und Rechenressourcen zu vermeiden, wenn man versucht, mehr Nutzen aus Software herauszuholen.

Die Sinnlosigkeit, wenn sich Prioritäten umkehren

• Selbst wenn eine Blockchain keine Bugs hat, ist das bedeutungslos, wenn sie ein Rug Pull ist.
• Selbst wenn die verwendete Sprache memory-safe ist, ist das bedeutungslos, wenn es kein Design für Korrektheit gibt und keinen Prozess, in dem letztlich alle Bugs behoben werden.
• Selbst wenn Software ein schönes Abstraktionsdach (canopy of abstractions) besitzt, ist das bedeutungslos, wenn sie miserabel funktioniert und niemand sie warten oder neue Funktionen hinzufügen kann.

Manchmal verliere ich an Energie, manchmal gehe ich in die falsche Richtung, und manchmal mache ich bewusst einen Umweg, aber niemand kann mich dazu bringen, mein wahres Ziel mit etwas Niedrigerem zu verwechseln.
Meine Erfahrung als Entwickler ist mir wichtig, aber nur insofern, als sie mir dabei hilft, mehr Software zu schaffen, die andere Menschen und ihr genießen könnt.

• Das letztendliche Ziel ist, den Nutzen für Endnutzer zu maximieren, und alles andere ist ein Mittel, um dieses Ziel zu erreichen.
  • Das ist das wichtigste Prinzip bei der Entwicklung von Software.

[GN⁺]

Lobste.rs-Kommentare

• Ich bevorzuge einen ähnlichen Ansatz
  Selbst Werkzeuge, die nicht gerade „liebenswert“ sind, wie Schraubendreher, können sehr lange zuverlässig sein. Ein Kreuzschlitzschraubendreher hat immer einen Kreuzschlitzkopf; wenn man ihn aus dem Werkzeugkasten nimmt, wird er nicht mit 1% Wahrscheinlichkeit plötzlich zu einem Schlitzschraubendreher, sodass man ihn wieder zurücklegen und noch einmal herausnehmen muss. Auch das Griffdesign ändert sich nicht endlos, und man kann ein gekauftes Werkzeug einfach benutzen, bis es kaputtgeht.
  Es wäre schön, wenn mehr Software so wäre.

  • Ich frage mich, was mit „Werkzeuge, die nicht gerade liebenswert sind, wie Schraubendreher“ gemeint ist.

• Ich respektiere und schätze Entwickler, die sich an den Maßstab halten: „Das Endziel ist, den Nutzen für den Endnutzer zu maximieren, und alles andere dient diesem Ziel“, aber ich selbst lebe nicht immer so. Ich denke, dass Software außer dem Endnutzer noch weitere legitime Verantwortungsbereiche hat.
  Beruflich entwickle ich Software, um meine Familie zu ernähren, und ich stehe ziemlich oft auf der Seite der Nutzer, aber letztlich ist meine Loyalität gegenüber dem zahlenden Unternehmen und meiner Familie größer.
  Bei persönlichen Projekten ist mein Maßstab, „ob diese Arbeit für mich erfüllend ist“, und künstlerische, ästhetische und intellektuelle Befriedigung sind wichtig. Meist deckt sich das mit dem Nutzen der Nutzer, aber ich kann den Nutzen für die Nutzer auch falsch einschätzen, und selbst wenn etwa bewiesen wäre, dass ein animiertes Hamburger-Menü den Nutzen maximiert, denke ich, dass ich in meinem Werk mein ästhetisches Wahlrecht ausüben und auf diesen Nutzen verzichten kann.

  • Unabhängig von solchen Abwägungen lässt sich außerdem nicht immer definieren, wer der eigentliche Endnutzer ist.
    Es gibt auch die Frage, wie man Fälle bewerten soll, in denen man absichtlich Teile der Software für die Nutzer unfreundlich macht, damit diese nicht irgendeinen absurden Unsinn anstellen, der den Nutzern ihrer eigenen Arbeit schadet.
    Wir haben einmal bewusst über solche Mechanismen gesprochen, um eine bestimmte Reporting-Funktion, die extrem anfällig für Goodharts Gesetz ist und deren Nebenwirkungen einen großen Wirkungsbereich haben, absichtlich für immer im Zustand „noch nicht verfügbar“ zu halten, obwohl die Nutzer der Software sie wollten.

• Erst durch diesen Beitrag habe ich erfahren, dass Tiger Style jetzt eine Website hat.

• Es heißt gleichzeitig „niemand kann das warten, von neuen Features ganz zu schweigen“ und „alle Bugs beheben“, aber ich verstehe letztlich nicht, wie es möglich sein soll, alle Bugs zu beheben, ohne am Ende einen Feature-Freeze beim Umfang zu haben.

• Der Satz „Auch wenn eine Blockchain keine Bugs hat, ist das bedeutungslos, wenn es ein Rug Pull ist“ bringt drei Dinge in einen einzigen Satz.
  Die Effizienz von etwas zu steigern, ist bedeutungslos, wenn dabei neue Bugs entstehen, und selbst dann nur sinnvoll, wenn es kein Rug Pull ist.

• Auffällig ist, dass es keine Anforderung gibt, dass Software unbedingt von Menschen geschrieben werden muss. Das ist umso interessanter, weil ich Kristoff als Kernentwickler von Ziglang kenne.
  Ich möchte glauben, dass man auch mit KI-gestützter Entwicklung Software bauen kann, die diesen Anforderungen entspricht.
  Es macht Spaß, Code direkt von Hand zu schreiben, und es macht auch Spaß, etwas fertigzustellen, aber beides gerät manchmal in Konflikt.
  Entschuldigung, dass ich mit KI anfange, aber wegen der engen Beziehung zwischen Kristoff und der Zig-Community, der starken Position von Zig und der Tatsache, dass ich Ziglang ohnehin ständig evangelisiere, lässt sich das schwer trennen.

  • Ich finde eher, dass der dritte Punkt auf eine ablehnende Haltung gegenüber solchen Tools hindeutet. Was diese Tools erzeugen, sieht meistens nach nicht wartbarem Spaghetti-Code aus.
  • Es scheint einen Grund zu geben, warum dieser Beitrag nicht auf ziglang.org, sondern in Loris’ persönlichem Blog erschienen ist.
    Nur weil ein Projekt eine klare Position zu Code auf Basis großer Sprachmodelle hat, heißt das nicht, dass alle Beteiligten dieses Projekts dieselbe Position für dieses oder für alle Projekte teilen.
    Das gilt nicht nur für Loris persönlich; bei solchen Entscheidungen ist eine Einzelfallbewertung vernünftig.