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 hat direkte nachgelagerte Auswirkungen auf Leistung, Bugs und Entwicklungsgeschwindigkeit
• Die Aussage „Nutzer interessieren sich nicht für den Tech-Stack oder Tests“ ist oberflächlich betrachtet richtig, doch 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, beeinflussen die Ergebnisse Sicherheit und Vertrauen, auch wenn Nutzer den Prozess selbst nicht sehen
• Dass diese Art von Gemeinplatz populär ist, könnte daran liegen, dass ein Ich-Verteidigungsmechanismus wirkt, mit dem man das abwertet, worin man selbst nicht gut ist
• Ernsthafte Softwarearbeit ist eine Mischung aus unterschiedlichen Interessen und Perspektiven, und all diese tragen zu Erfolg oder Misserfolg bei; daher sollte man Codequalität nicht auf die leichte Schulter nehmen

---

Wiederkehrende Klischees und ihre Grenzen

• In der Softwarebranche hört man immer wieder Aussagen wie
  • „Kunden interessieren sich nicht für Tests, sondern nur dafür, dass das Produkt funktioniert“
  • „Nutzer interessieren sich nicht für den Tech-Stack“
  • „Technische Eleganz ist nicht dasselbe wie Marktwert“
  • „Nutzer interessiert nicht, ob etwas von einer AI oder einem Menschen geschrieben wurde oder welches Framework verwendet wurde; sie wollen nur, dass das Produkt funktioniert“
• All diese Aussagen sind Varianten desselben Themas: „Kunden interessiert das nicht“
• Dabei wird so getan, als würde ein erfahrener Pragmatiker idealistischen oder kurzsichtigen Menschen die harte Wahrheit über die Welt erklären
• Aber das ist alles Unsinn (horseshit), und
  wenn man dieselbe Logik auf andere Bereiche anwendet, werden die Schwachstellen sichtbar
  • Straßennutzer interessieren sich nicht dafür, ob eine Brücke eine Abschlussinspektion erhalten hat, sondern nur dafür, ob sie ihr Auto trägt
  • Passagiere interessiert nicht, ob der Pilot betrunken ist, sondern nur, ob das Flugzeug pünktlich ankommt
  • Büroangestellte interessieren sich nicht dafür, ob das Fundament eines Hochhauses stabil ist, sondern nur dafür, Geld zu verdienen
• Diese Vergleiche stimmen oberflächlich, ignorieren aber offensichtliche nachgelagerte Auswirkungen (downstream effects)

Ignorierte nachgelagerte Auswirkungen

• Es stimmt zwar, dass Kunden sich nicht für die inhärenten Eigenschaften von Computercode interessieren, doch
  die Codequalität beeinflusst Leistung, das Vorhandensein von Bugs, die Zeit zur Behebung von Bugs und die Zeit zum Hinzufügen neuer Funktionen
• Je schlechter der Code ist, desto schwieriger und langsamer lassen sich diese Probleme lösen
• Unternehmen wie AirBnB, OpenAI und Meta können solche Bedenken mit enormer Marktmacht, massiver VC-Finanzierung und fragwürdiger Legalität wegdrücken
  aber wenn man kein solches Unternehmen ist, ist es schwer, Probleme auf dieselbe Weise zu überdecken

Die Beständigkeit von „Folk Wisdom“ und die vielen Interessen in der Software

• Die zähe Lebensdauer von Gemeinplätzen (The Persistence of Folk Wisdom)

  • Die Vorstellung, dass nur Erstwirkungen wichtig seien, hat sich in der Softwarewelt als sehr populäre Volksweisheit etabliert
  • Menschen neigen dazu, das abzuwerten oder kleinzureden, worin sie selbst nicht gut sind
  • Wenn man wahrnimmt, dass einem die Fähigkeit fehlt, guten Code zu schreiben, neigt man leichter zu der Sichtweise, dass guter Code nicht nur unwichtig ist, sondern dass Menschen, die guten Code schreiben können, sogar das Problem seien
  • Aus dieser Perspektive gelten dann diejenigen als Problem, die einen Release wegen Dingen aufhalten, die Kunden angeblich nicht interessieren
  • Diese Haltung wirkt als Ich-Verteidigungsmechanismus (ego defence mechanism), der eigene Schwächen vermeidet und die Verantwortung auf andere abwälzt

• Wir leben in einer Gesellschaft (We Live in a Society)

  • Ernsthafte Softwarearbeit ist eine Mischung aus unterschiedlichen Interessen und unterschiedlichen Perspektiven
  • Von Tech-Sales bis zum Tech-Stack, von User Experience (UX) bis zu eindeutigen Kennungen (unique identifiers) fließen viele verschiedene Elemente in Softwarearbeit ein
  • All diese Elemente tragen zu 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.