Nutzer kümmern sich nicht darum — aber Sie sollten es tun

• Nutzer legen mehr Wert darauf, dass ein Produkt funktioniert, als auf die inhärenten Eigenschaften des Codes selbst, aber schlechter Code wirkt sich direkt nachgelagert auf Leistung, Bugs und Entwicklungsgeschwindigkeit aus
• Die Aussage „Nutzer kümmern sich nicht um den Tech-Stack oder Tests“ ist oberflächlich betrachtet zwar richtig, aber je niedriger die Codequalität, desto schwieriger und langsamer werden Bugfixes und das Hinzufügen neuer Funktionen
• Wie die Vergleiche mit Brückeninspektionen, betrunkenen Piloten und instabilen Gebäudefundamenten zeigen, beeinflusst das Ergebnis Sicherheit und Vertrauen, auch wenn Nutzer den Prozess selbst nicht sehen
• Unternehmen wie AirBnB, OpenAI und Meta können solche Probleme dank Marktmacht, massiver VC-Unterstützung und fragwürdiger Legalität wegdrücken, aber nicht jedes Unternehmen befindet sich in einer solchen Position
• Der Erfolg von Software ist das Ergebnis des Zusammenspiels vieler Interessen und Perspektiven – von Vertrieb über Tech-Stack und User Experience bis hin zu eindeutigen Identifikatoren

---

Wiederkehrende Klischees und ihre Grenzen

• In der Softwarebranche wiederholen sich Aussagen wie: „Kunden kümmern sich nicht um Tests, sondern nur darum, dass das Produkt funktioniert“, „Nutzer kümmern sich nicht um den Tech-Stack“, „technische Eleganz ist nicht dasselbe wie Marktwert“ oder „Nutzer kümmern sich nicht darum, ob AI oder ein Mensch den Code geschrieben hat oder welches Framework verwendet wurde, sondern nur darum, dass das Produkt funktioniert“
• All diese Aussagen sind Varianten desselben Themas – „Kunden kümmern sich nicht darum“ – und werden in einer Form präsentiert, die wie pragmatischer Realismus klingen soll
• Wendet man dieselbe Logik auf andere Bereiche an, wird die Oberflächlichkeit des Problems sichtbar
  • So etwa die Aussage, Straßenbenutzer kümmerten sich nicht um die abschließende Prüfung einer Brücke, sondern nur darum, dass sie Autos trägt
  • Oder die Aussage, Passagiere kümmerten sich nicht darum, ob der Pilot betrunken ist, sondern nur darum, dass das Flugzeug pünktlich ankommt
  • Oder die Aussage, Büroangestellte kümmerten sich nicht um die Stabilität des Fundaments eines Hochhauses, sondern nur darum, Geld zu verdienen
• Diese Vergleiche sind oberflächlich betrachtet zwar richtig, ignorieren aber offensichtliche nachgelagerte Auswirkungen
• Es stimmt, dass Kunden sich nicht für die inhärenten Eigenschaften von Computercode interessieren, aber die Codequalität beeinflusst Leistung, das Vorhandensein von Bugs, die Zeit für Bugfixes und die Zeit für das Hinzufügen neuer Funktionen
• Je schlechter der Code ist, desto schwieriger und langsamer wird es, diese Probleme zu lösen
• Es wird darauf hingewiesen, dass Unternehmen wie AirBnB, OpenAI und Meta solche Bedenken mit enormer Marktmacht, massiver VC-Unterstützung und fragwürdiger Legalität wegdrücken können
• Das Fazit lautet, dass es ohne eine solche Unternehmensposition schwer ist, Probleme auf dieselbe Weise zu überdecken

Die Beständigkeit der „Volksweisheit“ und die vielen Interessen der Software

• Die Beständigkeit der Volksweisheit

  • Die Vorstellung, dass nur Effekte erster Ordnung wichtig seien, existiert in der Softwarewelt als sehr populäre Alltagsüberzeugung
  • Menschen neigen dazu, Dinge abzuwerten oder kleinzureden, in denen sie nicht gut sind
  • Wenn man erkennt, dass einem die Fähigkeit fehlt, guten Code zu schreiben, ist man eher geneigt, nicht nur zu behaupten, guter Code sei unwichtig, sondern auch die Menschen, die guten Code schreiben können, als das eigentliche Problem zu betrachten
  • Aus dieser Perspektive erscheinen diejenigen als Problem, die einen Release wegen Dingen aufhalten, um die Kunden sich angeblich nicht kümmern
  • Diese Haltung funktioniert als Ego-Abwehrmechanismus, mit dem man den eigenen Schwächen ausweicht und Verantwortung nach außen verlagert

• Wir leben in einer Gesellschaft

  • Ernsthafte Softwarearbeit ist eine Mischung aus unterschiedlichen Interessen und unterschiedlichen Perspektiven
  • Von technischem Vertrieb bis zum Tech-Stack, von User Experience bis zu eindeutigen Identifikatoren fließen viele verschiedene Elemente in Softwarevorhaben ein
  • All diese Elemente tragen zum Erfolg oder Misserfolg bei

[GN⁺]

Lobste.rs-Kommentare

• Solche Aussagen können sowohl in der Vermittlung als auch in der Rezeption gut oder schlecht sein.
  Zum Beispiel kann man „Kunden interessieren sich überhaupt nicht für Tests. Sie interessieren sich dafür, ob das Produkt funktioniert“ nicht als „liefert Bugs aus“, sondern als Aufforderung lesen, sich eher auf das tatsächliche Funktionieren des Produkts als auf eine bestimmte Test-Ideologie zu konzentrieren.
  Tests sind nur eines von mehreren Mitteln, um Code zum Laufen zu bringen; wenn also die Testabdeckung hoch ist und alles grün ist, das Produkt aber nicht funktioniert, dann ist das ein Fehlschlag. Umgekehrt ist es auch okay, wenn das Produkt auf andere Weise gut funktioniert, und selbst ohne formale Dogmen ist es okay, wenn Bugs effektiv gefunden werden.
  Außerdem kann aus Sicht der Nutzer und des Geschäfts auch das Nichtvorhandensein eines Produkts oder Features ein Bug sein; Bugfixes und Feature-Releases sind also nicht immer sauber voneinander zu trennen.
  Allerdings habe ich in der Praxis auch erlebt, dass solche Aussagen tatsächlich im Sinne von „drückt euch vor der Arbeit und veröffentlicht Müll“ verwendet werden.

  • Zum Punkt „Aus Sicht von Nutzern und Business ist auch das Fehlen eines Produkts/Features ein Bug“ gibt es etwas, das ich als Autor nicht ausdrücklich behandelt habe.
    Die Vorstellung, dass schlechtes Programmieren selbst über mehrere Monate hinweg „praktisch“ sei, lehne ich vollständig ab.
    In einer Codebasis mit schlechtem Design und zu wenigen Tests neue Features zu entwickeln, ist langsam und teuer.
  • Es gibt auch viele Engineers, die glauben, „je mehr Unit-Tests, desto besser“, oder die tagelang Code optimieren, der gar kein Bottleneck ist; in solchen Fällen sind die obigen Lesarten ziemlich passend.
    Entwickler sollten darauf achten, ob sie ihre Zeit dort einsetzen, wo Wert entsteht, und idealerweise versteht auch das Management, warum solche Arbeiten gemacht werden.
    Wenn mangelndes Verständnis und falsche Anreizstrukturen zusammenkommen, landet man am Ende doch bei „drückt euch vor der Arbeit und veröffentlicht Müll“.

• Ehrlich gesagt wirken Leute, die so etwas sagen, oft selbst wie Menschen, denen Nutzer nicht besonders wichtig sind.
  Damit Nutzer ein funktionierendes Produkt bekommen, muss es im Entwicklungsprozess Mechanismen geben, die diese Wahrscheinlichkeit erhöhen — das hatte ich schon in einem Kommentar vor ein paar Tagen gesagt.
  Diese Haltung taucht oft in Situationen auf, in denen Nutzer gar keine gute Möglichkeit haben, ordentliches Feedback zum Produkt zu geben, und es auch keine echten Nutzungsmetriken gibt.
  Es gibt viele Fehlerszenarien, die Nutzer zwar nicht sofort sehen oder bewusst beachten, von denen sie aber trotzdem betroffen sind.
  Ein typisches Beispiel ist Sicherheit: Bis ihre Daten in einem Online-Leak auftauchen, ist Nutzern womöglich gar nicht bewusst, dass etwas „nicht sicher“ ist; und bei Performance merken sie vielleicht erst dann ein Problem, wenn sie erfahren, dass es eigentlich viel besser sein könnte.

  • Solche Themen sind für ein allgemeines Publikum schwer zu erklären.
    Bei Verbesserungsprozessen ist es schwer, gute Ergebnisse zu erzielen, wenn man nur ein einzelnes Element isoliert optimiert; für Fortschritt in einer Diskussion muss man es aber oft trotzdem so zuspitzen.
    Deshalb hilft es, die Diskussion entlang der Feedback-Pfade zu justieren, je nachdem, wo das sichtbare Problem tatsächlich liegt.
    Ich sehe solche Texte als einen Versuch, an Faktoren zu erinnern, die den Erfolg von Softwareprojekten beeinflussen, aber gegensätzlich wirken können.
    Es ist wertvoll, Dinge, die sonst nur technisch versierte Leute intuitiv verstehen, in Worte zu fassen und zu verteidigen; gleichzeitig scheint es vielen Technikern schwerzufallen, die Balance bei unsichtbarer Arbeit zu halten oder deren Wert überzeugend zu vermitteln, und ich übe das selbst weiterhin.

• Sich um das Innenleben zu kümmern, ist wichtig und nützt tatsächlich auch den Nutzern.

• Ich mag diese Perspektive.
  Ich will nicht ins andere Extrem des Overengineering kippen, aber ich wünschte, wir würden uns vom Denken „move fast and break things“ lösen.
  Meiner Erfahrung nach ist das in der Webentwicklung fast schon ansteckend.
  Ich hoffe, dass der Zustrom minderwertiger Software, den LLMs möglich gemacht haben, die Nutzer am Ende eher dazu bringt, verlässliche Software zu belohnen.
  Ich werde immer mehr zu einem grug-brain-Entwickler, also weiß ich nicht, wie weit dieses Gefühl verbreitet ist, aber ich bin müde von „lasst uns noch ein Feature hinzufügen“.
  Wir machen oft den Fehler, die Kosten von Software nur am Release-Datum zu messen, und berücksichtigen die Wartungskosten über ihre gesamte Lebensdauer kaum.
  Man sagt „Das ist nicht schwer, das dauert nicht mal eine Woche!“, erwähnt aber nicht die 2 bis 4 Wochen pro Jahr, die dann für Wartung, Fixes, Erweiterungen, Updates, Integration und Dokumentation draufgehen.

• Ich sage oft etwas in einer ähnlichen Richtung.
  „Dem Endnutzer ist es egal, ob die Software 100 % Test Coverage hat oder zu 100 % in undokumentiertem Assembly mit Labels wie lbl0 geschrieben wurde. Ihn interessieren Korrektheit, Performance und User Experience.“
  Aber Software Engineering hilft nun einmal genau dabei, diese Ziele leichter zu erreichen und die Qualität auf einem guten Niveau zu halten.
  Das Problem ist, dass auch dieser Weg in Cargo Cult und Overengineering münden kann, und daran bin ich definitiv selbst schuldig.
  Trotzdem muss am Ende echter Wert für den Nutzer geliefert werden.

• Wie bei Boeing und Airbus gibt es nachweisbar optimale Ergebnisse.
  Entscheidend ist nicht, warum die Flugzeuge beider Unternehmen so ähnlich aussehen oder wer zuerst entworfen hat und wer von wem geklaut hat.
  Niemand hat etwas geklaut; Weltklasse-Ingenieure aus unterschiedlichen Teams entwerfen unter denselben Zwängen, und Designs, die davon abweichen, sind per Definition unterlegen.
  Man muss auf der Pareto-Front liegen, sonst wird man gefressen.
  Auch in unserem Bereich gibt es irgendwo ein Optimum; die Frage ist, ob man die Werkzeuge, das Budget und die richtigen Leute hat, um dorthin zu kommen, und ob es genug Nutzer gibt, um überhaupt feststellen zu können, ob man dort angekommen ist.