12 Punkte von GN⁺ 2026-03-06 | 1 Kommentare | Auf WhatsApp teilen
  • Die wesentliche Aufgabe von Software besteht darin, das Problem, das sie lösen soll, klar zu kennen und ihre Grenzen zu erkennen
  • Gute Software versucht nicht, alle Funktionen abzudecken, sondern befasst sich nur mit den Bereichen, die verbessert werden müssen, und weicht nicht von ihrem Zweck ab
  • Anhand eines fiktiven Falls, in dem der Befehl ls durch eine AI-Funktion ersetzt wird, wird das Phänomen unnötiger Ausweitung bestehender Werkzeuge satirisch dargestellt
  • Unter Berufung auf die in 37Signals’ „Getting Real“ und „Rework“ formulierten Prinzipien wird betont, dass man Beschränkungen als Vorteil nutzen und unnötige Feature-Anfragen ablehnen sollte
  • Auch im AI-Boom wird daran erinnert, dass die Stabilität bestehender Standards und eine klare Problemdefinition wertvoller sind als neue Trends

Die Rolle und Grenzen von Software

  • Der Text beginnt mit einer imaginierten Szene, in der nach einem Update einer Linux-Distribution der Befehl ls in eine AI-basierte Verzeichnisintelligenz verwandelt wird
    • Der neue Befehl als sagt die Absicht des Nutzers voraus, priorisiert Dateien und zeigt die Meldung an, dass die Unterstützung für das bisherige ls in 30 Tagen eingestellt wird
    • Diese Szene ist ein satirisches Beispiel für Feature-Overload und unnötige Innovation
  • Mit den Worten „Zum Glück passiert so etwas in Wirklichkeit nicht“ wird betont, dass gute Software weiß, wann sie aufhören muss

Die Kernprinzipien guter Software

  • Gute Software weiß, welchem Zweck sie dient, versucht nicht, alles zu können, und unterscheidet zwischen dem Zeitpunkt zum Aufhören und dem, was verbessert werden sollte
  • Die menschliche „maximalistische Denkweise“ neigt dazu, alles größer und komplexer zu machen
  • Software muss jedoch ihre Rolle und Position klar definieren; wenn eine neue Idee nicht zur bestehenden Vision passt, sollte sie in ein separates Projekt ausgelagert werden

Die Produktphilosophie von 37Signals

  • „Rework“ und „Getting Real“, geschrieben von den Basecamp-Gründern, liefern wichtige Lehren für das Produktdesign
    • Beschränkungen sind Vorteile (Constraints are advantages): Kleine Teams, begrenzte Budgets und ein eingeschränkter Umfang fördern bessere Entscheidungen
    • Feature-Anfragen ignorieren (Ignore feature requests): Statt gewünschte Funktionen einfach umzusetzen, ist ein Ansatz nötig, der das grundlegende Problem versteht
    • Früh veröffentlichen, oft veröffentlichen (Ship early, ship often): Ein unvollkommenes, aber tatsächlich funktionierendes Produkt ist wertvoller als ein perfektes, das nie veröffentlicht wird
    • Epicenter-Design (Epicenter design): Statt Navigation oder Randaspekte zuerst zu gestalten, sollte man mit der Kernoberfläche und den zentralen Interaktionen beginnen
    • Standardmäßig Nein sagen (Say no by default): Neue Funktionen bringen versteckte Kosten mit sich, etwa mehr Komplexität, höhere Wartungskosten und zusätzliche Sonderfälle
    • Für den eigenen Bedarf bauen (Scratch your own itch): Ein Produkt, das ein Problem löst, das man selbst tatsächlich hat, ermöglicht bessere Entscheidungen

Der Wert von Beständigkeit gegenüber Veränderung

  • In letzter Zeit gibt es einen Trend, bei dem viele Produkte ihren Namen und ihre Funktionen rund um AI neu ausrichten
    • MinIO → AIStor
    • Oracle Database → Oracle AI Database
  • Nicht alles muss sich dramatisch verändern
  • In einem bestimmten Problembereich zum de-facto-Standard zu werden, hat den größeren Wert

1 Kommentare

 
GN⁺ 2026-03-06
Hacker-News-Kommentare
  • Beim Rat „Feature-Requests ignorieren“ musste ich an Blizzard und World of Warcraft Classic denken
    Jahrelang hatten Nutzer eine Classic-Version gefordert, aber Blizzard lehnte mit „Das wollt ihr gar nicht“ ab
    Am Ende veröffentlichten sie Classic WoW und es wurde ein überwältigender Erfolg
    Später räumte das Entwicklerteam ein, dass „die Nutzer tatsächlich wussten, was sie wollten“
    Man sollte also nicht immer pauschal Feature-Requests ignorieren, sondern anerkennen, dass Nutzer manchmal durchaus genau richtigliegen können

    • Selbst wenn eine Nutzeranfrage anfangs unsinnig wirkt, führt das Erklären, warum etwas nicht geht, bei höflichen Nutzern oft dazu, dass einem selbst eine bessere Lösung einfällt
      Unhöfliche oder egozentrische Nutzer machen das Gespräch dagegen anstrengend, sodass man am Ende gar nicht mehr reagieren will
      Die Lehre ist also: Wer etwas will, sollte höflich fragen
    • „Nutzeranfragen ignorieren“ klingt auf den ersten Blick gut, aber treffender wäre: „Verstehe, was der Nutzer eigentlich sagt“
      Danach muss man beurteilen, ob es eine sinnvolle Anfrage ist, und überlegen, wie man sie umsetzen könnte
    • Im Fall von Blizzard zeigt sich, dass die Nutzer nicht einfach nur eine Classic-Version wollten, sondern sich gegen die komplexen Systeme des modernen WoW wandten
      Das eigentliche Problem war ein „Spiel, das sein ursprüngliches Gefühl verloren hat“, und mit diesem Verständnis hätte man es vielleicht auch anders als mit Classic lösen können
    • Tatsächlich wissen oft weder Nutzer noch Entwickler oder PMs genau, was sie wirklich wollen
      WoW Classic war ein Ausdruck des oberflächlichen Wunsches, das „alte Gefühl“ zurückzubekommen, darunter lag aber ein Misstrauen gegenüber einer Entwicklungsrichtung, der man nicht traut
      In einer idealen Welt wäre vielleicht eine perfekte Mischung aus den Stärken beider Versionen möglich, aber in der Realität würde das wohl nur zu mehr Verwirrung durch widersprüchliche Meinungen führen
    • Ein Gegenbeispiel ist Ultima Online
      Dort fügte man auf Wunsch der Nutzer Nicht-PVP-Instanzen hinzu, wodurch die Spannung verschwand und das Spiel flach wurde
      In diesem Fall wussten die Entwickler offenbar mehr als die Nutzer
  • Ich finde, es sollte mehr fertige Software geben, die aufhört, Features hinzuzufügen
    Man braucht den Mut zu sagen: „Das reicht jetzt“
    Es gibt viele Beispiele wie Evernote oder Dropbox, die nach ihrer besten Phase durch Feature-Überfrachtung unübersichtlich wurden

    • Früher wurde die meiste Software tatsächlich genau so veröffentlicht
      Sie wurde in Schachteln verkauft, und wenn eine neue Version erschien, kaufte man eine neue Schachtel
      Das war die Zeit vor den ständig aktualisierten Web-Apps
    • Die meisten Programme erkennen nicht an, dass sie fertig sind
      Oft werden sie durch Updates sogar schlechter
      Produkte, die sich wirklich verbessern, sind eher selten
    • Erst nachdem ich diesen zugehörigen Kommentar gelesen hatte, verstand ich, warum dieses Phänomen entsteht
    • Dropbox hat seinen ursprünglich einfachen Zweck verloren und ist wieder zu einem komplexen Netzwerk-Dateisystem geworden
      Am Ende hat es das Problem, das es ursprünglich lösen wollte, selbst wieder erzeugt
    • Früher gab es eine einfache iOS-To-do-App namens Task Eater, deren Entwickler erklärte: „Sie ist jetzt fertig“, und die Updates einstellte
      Mit der Zeit wurde sie jedoch mit neuen iOS-Versionen inkompatibel und war schließlich nicht mehr nutzbar
      Das ließ mich zugleich die Schönheit der Vollendung und die Grausamkeit technischer Weiterentwicklung spüren
  • Als ich 2020 von Infrastruktur zu einem Java-Entwickler wechselte, sah ich viele zentrale Bibliotheken im Wartungsmodus und dachte zuerst: „Ist Java tot?“
    Später wurde mir klar, dass sie einfach funktional fertig waren
    Sie hatten einen stabilen Zustand erreicht, in dem unzählige Edge Cases bereits gelöst waren
    Das Problem ist nur, dass Menschen solche Stabilität nicht wollen, sondern immer etwas Neues
    Deshalb baut man letztlich immer wieder dieselben Frameworks, nur in einer anderen Sprache

    • Viele haben Angst, dass bei einer Bibliothek im Wartungsmodus Bugs vielleicht nicht mehr behoben werden
      Deshalb bevorzugen sie Projekte, die noch aktiv weiterentwickelt werden
      Manche Unternehmen dürfen wegen Compliance-Anforderungen sogar nur Software einsetzen, die fortlaufend Updates erhält
    • Ich bin früher einmal von einer Java-Memcached-Bibliothek im Wartungsmodus auf Redis umgestiegen
      Ich machte noch den Scherz: „Sie ist halt einfach fertig, da gibt es nichts mehr zu verbessern“, aber gewechselt habe ich trotzdem
  • Ich mag Sublime Text wegen seiner Einfachheit und Geschwindigkeit
    Es stopft nicht AI oder komplexe Funktionen hinein, sondern konzentriert sich auf einen einzigen Zweck

    • Deshalb benutze ich immer noch vim
  • Gute Software ist nicht zwangsläufig Software, die Geld verdient
    Aber wenn man Geld verdienen will, braucht man Funktionen, die Menschen tatsächlich nutzen
    Da jeder Nutzer seine eigenen anderen 20 % an Funktionen verwendet, muss man diese Vielfalt mitdenken

  • Ich hielt Notepad.exe immer für ein Paradebeispiel fertiger Software,
    war dann aber schockiert, dass man unter Windows 11 die Dateizuordnung nur mit Manipulationen auf Hack-Niveau ändern kann

  • Ich erkenne die Schönheit fertiger Software an, aber heute ist fast alles in einem Zustand des „ewigen Beta
    Weil Internetverbindung vorausgesetzt wird, ist eine Struktur entstanden, in der „jederzeit Updates möglich“ sind,
    und Bugfixes lassen sich nicht von unerwünschten neuen Features trennen
    Bei Webdiensten wie YouTube kann man nicht einmal eine Version auswählen

    • Ich bin von Evernote zu Obsidian gewechselt, aber auch Obsidian wird zunehmend featurelastig
      Vor allem mit der Einführung der Canvas-Funktion geriet die ursprüngliche einfache Philosophie ins Wanken
      Wäre es Open Source, hätte ich es an diesem Punkt vielleicht geforkt
  • Signal ist kostenlos, Open Source und auf Privatsphäre ausgerichtet, deshalb hat es weniger Funktionen
    Gerade das gefällt mir aber

    • Trotzdem ist schon allein die zeitversetzte Sendefunktion deutlich nützlicher als bei WhatsApp
      WhatsApp häuft dagegen nur unnötige Funktionen an
  • Früher verstand ich nicht, wie wichtig das in einem 37signals-Buch beschriebene „immer Wichtige“ (evergreen) ist, insbesondere Geschwindigkeit
    Aber je mehr ich sehe, wie Apps mit der Zeit immer langsamer werden, desto klarer wird mir, wie groß der Wert schneller Software ist

  • Ich musste an den Satz aus Neal Stephensons 『REAMDE』 denken: „Schriftsteller mögen Residenzen
    So wie Schriftsteller sich ständig Arbeit schaffen, um ihre Residenzen zu erhalten, neigen auch Entwickler dazu, Code zu verändern, um sich Arbeit zu schaffen

    • Ich habe unzählige Male gehört: „Wir müssen die Codebase komplett in Architektur X oder Sprache Y neu schreiben“
      Am Ende wiederholen auch wir ständig Veränderung um der Veränderung willen