Code wird häufiger ausgeführt als gelesen

• Das Prinzip „Code wird häufiger gelesen als geschrieben“ beginnt mit der Priorisierung des Wartenden vor dem Autor und erweitert sich zu einem Entscheidungsmodell, das auch Nutzer, Betrieb und Business berücksichtigt.
• Der Wert von Code liegt nicht in seiner Raffinesse an sich, sondern darin, ob er den Zweck der Nutzer erfüllt; wichtig ist, ihn Nutzern früh und oft zu zeigen und Feedback einfließen zu lassen.
• Code in Produktion „auszuführen“ bedeutet, den gesamten Lebenszyklus einzuschließen: Deployment, Upgrades, Beobachtung, Audits, Monitoring, Korrekturen und Außerbetriebnahme; die langfristigen Betriebskosten können weit größer sein als Unannehmlichkeiten während der Entwicklung.
• KISS erweitert sich über bloße Vereinfachung von Code hinaus zu einem Betriebsprinzip: weniger bewegliche Teile, Fehlermodi verstehen und Systeme so bauen, dass sie auch bei Fehlern weiter funktionieren.
• Da Budget, Marketing, Deadlines, Stakeholder, Investoren und politische Interessen in Entscheidungen hineinspielen, muss man anerkennen, dass Nutzer glücklich zu machen und Umsatz zu erzeugen nicht immer dasselbe ist.

---

Erweiterung des Prioritätsmodells

• Die Aussage „Code wird häufiger gelesen als geschrieben“ bedeutet, dass die Person, die den Code zuerst schreibt, die Kosten für diejenigen nicht ignorieren sollte, die ihn später lesen und ändern.
• Dieses Prinzip liefert die Begründung, in Wartbarkeit zu investieren, etwa in Einfachheit, Tests und Dokumentation.
• Komprimiert lässt sich das als das Modell maintainer > author verstehen.

Nutzer stehen vor Entwicklern

• Code ist ein Mittel zum Zweck, und Software muss irgendeiner Art von Nutzern einen Dienst leisten.
• Selbst hervorragend geschriebener Code oder ausgefeilte Technik verlieren an Wert, wenn sie den Zweck nicht erfüllen und keine gute User Experience bieten.
• Die Priorität erweitert sich zu user > maintainer > author, und wenn man Entwicklerrollen nicht trennt, wird daraus user > dev.
• Statt nur zu raten, was Nutzer wollen, oder sie bloß zu fragen, ist es besser, ein Programm früh und häufig vor Nutzer zu bringen und das Gelernte aus dem Feedback einzuarbeiten.

Ausführung umfasst auch den Betrieb in Produktion

• „Ausführen“ ist nicht bloß das Starten eines Programms, sondern umfasst den gesamten Prozess des Betriebs in Produktion.
  • Deployment
  • Upgrade
  • Beobachtung
  • Audit
  • Monitoring
  • Korrektur
  • Außerbetriebnahme
• Dan McKinleys Choose Boring Technology vertritt die Ansicht, dass die langfristigen Kosten, ein System stabil am Laufen zu halten, fast immer viel größer sind als die Unbequemlichkeiten beim Bauen.
• Mit dieser Perspektive wird das Modell zu user > ops > dev.
• Viel Software erreicht nie eine Produktion in sinnvoller Größenordnung und wird auf ungetesteten Annahmen aufgebaut.
• Wenn Code in Produktion betrieben wird, wird KISS über die Code-Ebene hinaus zu einer Frage, bewegliche Teile zu reduzieren und Fehlermodi zu verstehen.
• Entscheidend ist, überhaupt etwas zu deployen und sicherzustellen, dass es auch dann funktioniert, wenn etwas schiefgeht.

Business ist eine eigene Achse

• Mit Blick auf die Nutzer zu entwickeln, bringt einen weit, aber die Annahme „Software, die für Nutzer wertvoll ist, ist auch für die Organisation wertvoll“ ist eine vereinfachte Abstraktion.
• Aus Entwicklersicht ist es leicht, gutes Softwarebauen und die Monetarisierung durch das Business zu trennen, aber am Ende kommt der Punkt, an dem die Business-Perspektive in den Arbeitsprozess einbezogen werden muss.
• Diese Unterscheidung funktioniert im Großen und Ganzen bei Consumer-Software und Enterprise-Software.
• Das Modell erweitert sich zu biz > user > ops > dev.
• Das klarste Beispiel ist das Budget: Da die Ressourcen zur Erfüllung von Nutzeranforderungen nicht unbegrenzt sind, müssen Kosten und Nutzen gemessen werden.
• Marketing, Deadlines, Stakeholder, Investoren, persönliche Interessen und Politik beeinflussen Entscheidungen ebenfalls.
• Eine Entscheidung, die richtig erscheint, wenn man nur Software, Team und Nutzer betrachtet, muss für die gesamte Organisation nicht die richtige sein.
• Manchmal muss man statt Nutzer zu begeistern Umsatz erzeugen.

Gerüche von Entwicklungsorganisationen im Modell

• Unwartbarer Code: author > maintainer

  • Kluger, aber fauler Code wird zu Spaghetti und einem „Geisterwald“.
  • Dazu gehören Probleme wie verfrühte Optimierung oder Module, die nur eine bestimmte Person anfassen kann.

• Unbenutzbare Software: dev > user

  • Entsteht in Teams, die nicht von Nutzern lernen oder Technik priorisieren.
  • Beispiele sind überengineerte Programme, „Modernisierungen“, die die User Experience verschlechtern, oder Web-Apps, die Browserfunktionen kaputtmachen.

• „Auf meinem Rechner funktioniert es“: dev > ops

  • Gemeint ist Software, die nicht mit Blick auf den Betrieb entworfen wurde.
  • Dazu zählt übermäßige Komplexität, etwa eine schicke Datenbank für geringe Datenlast oder ein ganzes Microservices-Ökosystem, das von einem kleinen Team betrieben wird.
  • Auch Software, bei der die Person, die nachts bei Störungen geweckt wird, nicht dieselbe ist wie die Person, die sie entworfen hat, gehört dazu.

• „Das Richtige“: dev > biz

  • Hier wird Code behandelt, als sei er Selbstzweck.
  • Beispiele sind aufgeblasene Handwerker, die Musiker auf der Titanic und Lisp Hackers.

• Lebenslaufgetriebene Entwicklung: dev > *

  • Das ist Software, die entsteht, wenn nichts auf dem Spiel steht und Entwickler tun können, was sie wollen.

• Eingebildete Software: biz > user > ops > dev

  • Das ist Software, die gebaut wurde, aber fast nie oder gar nicht in Produktion geht.
  • Charity Majors nennt das living a lie.
  • Auch Software ohne Nutzer gehört dazu, wenn sie kein Problem löst, das falsche Problem löst oder ein Problem löst, das niemand je hatte.
  • Dazu zählt auch, mit übertriebener Technologie auf alles einzuschlagen, bis etwas wie ein vager Use Case aussieht.

• „Spätkapitalismus“

  • Gemeint ist Venture-finanzierte Software, die entweder kein Geschäftsmodell hat oder erst zum Monopol wächst und dann Nutzer ausbeutet.

Die Spannung zwischen Nutzern und Business

• biz > user hat schwer akzeptierbare Folgen.
• Die Art, wie viele Software gelernt haben, war das Lösen von Problemen für Endnutzer, und einer der letzten Tipps in The Pragmatic Programmer lässt sich auf das Ziel verdichten, nicht bloß Code auszuliefern, sondern Nutzer zu begeistern.
• Je allgegenwärtiger Software wird, desto schwieriger wird es, diese Annahme aufrechtzuerhalten.
• Viel Software kümmert sich nicht um Nutzer, manipuliert sie oder macht sie selbst zum Produkt.
• Dieses Problem ist nicht auf Social Media beschränkt.
  • Beim Buchen von Zimmern, Bestellen von Essen oder Klicken auf den Start-Button von Windows erscheinen Pop-ups, die um die Aufmerksamkeit der Nutzer kämpfen.
  • Über die Google-Suche wird gesagt, man bekomme Ergebnisse wie aus einem Müllhaufen.
• Die Diskrepanz zwischen dem Glauben, gute Arbeit zu tun, und dem, was ein großer Teil der Branche für profitabel hält, erklärt das Unbehagen vieler Softwareprofis.
• Wir können nicht in eine Vergangenheit zurückkehren, in der wirtschaftliche Realität ignoriert wurde, aber wir brauchen eine stärkere ethische Haltung, um Nutzern nicht zu schaden.
• Nutzer können nicht immer vor dem Business stehen, aber auch das Business darf nicht bedingungslos an erster Stelle stehen.
  • user > ops > dev
  • biz > ops > dev
  • biz ≹ user

[GN⁺]

Hacker-News-Kommentare

• Manche nutzen ein System nicht, weil sie es mögen, sondern weil ihre Firma es gekauft hat
  In so einer Situation hat per Definition das Business Vorrang vor den Nutzern, und Entwickler richten sich eher nach den Anforderungen des mittleren Managements auf Kundenseite als nach den tatsächlichen Nutzern. Andernfalls bekommt man den Vertrag nicht. Am Ende sitzen die Nutzer mit halbherzig bereitgestellten Funktionen fest, während das Entwicklungsteam damit beschäftigt ist, neue Features zu bauen, die dem mittleren Management gefallen
  Das ist etwas zynisch, aber als Engineer ist es hilfreich zu wissen, ob man grundsätzlich in genau so einer Art von Firma arbeitet. Onlinehändler sind zum Beispiel sehr sensibel gegenüber Nutzern und betreiben teils unterschiedliche Website-Versionen je nach Land, weil Deutsche X mögen und Amerikaner Y. Schon kleine Änderungen können große Unterschiede beim Umsatz machen
  Andere Firmen hingegen reagieren kaum auf Usability, weil die Person, die das Produkt kauft, nicht der tatsächliche Nutzer ist

  • Ich habe mal bei einer Firma gearbeitet, die SaaS an Großunternehmen verkauft hat
    Um Verträge zu gewinnen, mussten wir die Checklisten der Kunden erfüllen, aber wir haben uns auch um die User Experience gekümmert. Eine gute User Experience war fast nie eine harte Anforderung des Kunden
    Die Software der Konkurrenz war extrem schmerzhaft zu benutzen, deshalb wollten wir uns genau dort differenzieren. Das erleichterte Schulungen, machte die Nutzer zufriedener, und wenn möglich empfahlen sie ihren Vorgesetzten sogar, mehr von unserem Produkt zu kaufen
    Letztlich kamen 80 % davon aus Stolz und Empathie im Sinne von „unsere Software ist nicht furchtbar“, aber langfristig war es auch in unserem Interesse, weil sich dadurch die Marke aufbaute
  • Ich habe in einem Markt mit ähnlicher Kaufstruktur gearbeitet, und wir haben uns nur auf die Nutzer konzentriert
    Wir haben eine Product-Led-Growth-Strategie gewählt, hatten keine Vertriebsleute, und das Produktteam konzentrierte sich vollständig auf die User Experience. Das Problem war, dass wir nicht an die Nutzer verkauft haben. Die Käufer der Software waren andere Menschen innerhalb der Nutzerorganisation und hatten das Produkt selbst nie benutzt
    Das war ein zwangsläufig scheiternder Ansatz. Wir brauchten Vertriebsleute, die verstehen, wie Käufer denken, ihnen die Vorteile erklären und die Nutzer dabei coachen, die Vorteile intern anderen Personen in ihrer Organisation zu erklären. Man musste die Lücke zwischen Nutzern und Käufern überbrücken
  • Normalerweise sind auch mittlere Manager Nutzer, aber innerhalb der Nutzerschaft eine Minderheit, und sie verwenden andere Funktionen, etwa Berichte
    Deshalb geht es darum, welche Nutzer man priorisiert, und man muss ein Gleichgewicht finden zwischen der Priorisierung der Erfahrung einer Minderheit, die Einfluss auf den Rest der Nutzer hat, und der Sicherstellung, dass der Rest der Nutzer das Produkt ausreichend verwenden kann, um dem Management sinnvolle Daten zu liefern
  • Ich habe so etwas bei einer Firma erlebt, die Software an Stadtverwaltungen verkauft hat
    Wichtig waren nur die Meinung des Bürgermeisters, des Stadtmanagers und des Stadtrats. Wenn die Berichte gut aussahen und der Preis passte, wurde verlängert
    Ich erinnere mich an Meetings vor Ort, in denen die Menschen, die es täglich benutzten, uns direkt ins Gesicht sagten, wie furchtbar es sei. Trotzdem wurde ausnahmslos jeder Kunde mit dem Versprechen, ein paar bestimmte Bugs zu beheben, und einer minimalen Preiserhöhung verlängert
  • Dass Entwickler sich nach den Anforderungen des mittleren Managements auf Kundenseite richten statt nach den tatsächlichen Nutzern, ist der Grund, warum Enterprise-Software insgesamt so schlecht ist

• Heute habe ich das Symbol ≹ kennengelernt. Es soll „eine Beziehung darstellen, in der keines von zwei verglichenen Objekten größer oder kleiner als das andere ist, man sie aber auch nicht notwendigerweise als gleich bezeichnen kann. Eine wichtige Feinheit in Bereichen, in denen Vergleiche nicht strikt numerisch sind“ (https://www.mathematics-monster.com/symbols/Neither-Greater-...)

  • Das Beispiel mit komplexen Zahlen z_1, z_2 und z_1 ≹ z_2 wirkt seltsam
    Es wäre doch klarer, einfach |z_1| = |z_2| zu schreiben, also dass die beiden komplexen Zahlen denselben Betrag haben
    Dort steht: „Zusammenfassend spielt das Symbol ≹ eine wichtige Rolle dabei, einen Zwischenbereich zwischen traditionellen Relationsoperatoren bereitzustellen“, aber ich bin Doktorand in Mathematik und habe es noch nie gesehen. Dass es eine wichtige Rolle spielt, fällt mir schwer zu glauben
  • Dieses Glyph sollte das Ergebnis einer Kombination aus Apfel-Emoji und Orangen-Emoji sein
  • Das erinnert mich an den Spiel-Begriff in der kombinatorischen Spieltheorie
    Spiele sind eine Obermenge der surrealen Zahlen, und surreale Zahlen sind eine Obermenge der reellen Zahlen; man lockert dabei die Definition surrealer Zahlen, sodass die Eigenschaft der Totalordnung verloren geht
    Dadurch entstehen seltsame Zahlen, die mit anderen Zahlen „verwechselt werden können“ oder „fuzzy“ sind. Das einfachste Beispiel ist * (star), das weder größer noch kleiner als 0 ist und deshalb mit 0 verwechselt wird. Es ist wie eine fuzzy Wolke um 0 und wird als 0║* notiert
    Komplexere Spiele, sogenannte Switches, können mit größeren Zahlenbereichen verwechselt werden und gelten als „hot“. Baut man Zahlen aus Switches, kann man noch interessantere heiße Spiele konstruieren
  • Ich halte dieses Konzept für wichtig, um die kausale Ordnung in verteilten Systemen zu verstehen, zum Beispiel im Kontext von CRDTs
    Ereignisse, die auf einem einzelnen Gerät erzeugt werden, haben immer eine vollständige Ordnung. Werden aber auf zwei Geräten im Offline-Zustand Ereignisse erzeugt, kann man nicht sagen, welches zuerst war, und zwischen den beiden Ereignissen entsteht eine ≹-Beziehung. Anders gesagt betrachtet man die Ereignisse als gleichzeitig
    Dadurch können Ordnungen wie „d > b > a“ und „d > c > a“ entstehen, aber dann gilt „c ≹ b“
    Einen deterministischen Umgang mit solchen Gleichständen zu definieren, ist ein großer Teil des Problems, das CRDTs lösen
  • Im „Beispiel 1: numerischer Kontext“ des Links geht es um zwei reelle Zahlen a und b, und dort steht, wenn a weder größer noch kleiner als b sei, aber auch nicht ausdrücklich gleich, dann sei die Relation ≹
    Wie soll das möglich sein?

• Für viele von uns könnten die Kosten, Code eine Milliarde Mal auszuführen, geringer sein als ein paar Minuten Entwicklerzeit.
  Wenn man bei AWS 200 Dollar pro Monat für Serverkosten ausgibt, kann man einen großen Teil meines Web-API-Codes auch 100 Milliarden Mal ausführen.
  Deshalb ist Optimierung für menschliche Leser oft besser, und andere Optimierungen sollte man nur dann vornehmen, wenn nachgewiesen ist, dass der Code so langsam ist, dass es wirtschaftlich nicht tragbar wird.

  • Ich sehe das ähnlich, aber der Autor scheint den Titel unglücklich gewählt zu haben.
    Der Text endet ungefähr so:
    user > ops > dev
    biz > ops > dev
    biz ≹ user
    Das Fazit wirkt eher so, dass Code letztlich für Endnutzer und das Geschäft existiert. Das letzte Zeichen, ≹, drückt schön aus, dass die Anforderungen von Endnutzern und Business nicht identisch sind, aber für die Existenz des Codes beide gleich wichtig sind.
  • Das Problem bei der Rechnung „kostet weniger als Entwicklerzeit“ ist meist, dass die Person, die diese Kosten trägt, nicht dieselbe ist.
    Nutzer zahlen auf weniger offensichtliche Weise: durch höhere Stromrechnungen, verkürzte Lebenszeit[0], verpasste Chancen, größeren Frust und häufigere Hardware-Upgrades.
    Außerdem haben die meisten Nutzer weder das Gehalt noch die Lebensqualität von Entwicklern, daher trifft sie der Schaden um ein Vielfaches stärker.
    [0] Die Zeit anderer Leute zu verschwenden, verringert QALY.
  • Im Artikel wird „Ausführung“ nicht nur im Sinn von „ein Programm laufen lassen“ verwendet.
    Gemeint ist auch der Betrieb in Production, also alles rund um Deployment, Upgrades, Beobachtung, Audits, Monitoring, Fehlerbehebung und Ausmusterung.
  • Meiner Erfahrung nach sollte man auf Latenz achten, weil sie die User Experience beeinflusst. Bessere Latenz einfach mit Geld zu kaufen, ist ziemlich schwierig.
  • Ich hatte erwartet, dass die Reaktion eher in diese Richtung geht. Aber dieser Artikel ist ein anderer. Er ist einen Blick wert.

• Wenn man die Schlussfolgerung des Titels an den Autor zurückspiegelt, wäre es eher nicht „Code wird öfter gelesen als geschrieben“, sondern unlesbarer Code läuft nicht lange.
  Allerdings bin ich ein erfahrener Systemadministrator, der in die Entwicklung wechseln will, und in diesem Sinn ein völliger Anfänger.

  • Es gibt sehr viel verhärteten Code, den Leute aus Angst nicht anfassen, weil sie ihn nicht verstehen, obwohl das Business darauf aufbaut.
  • Proprietäre Software ohne Source Code, etwa Third-Party-Libraries oder fast alle Black-Box-Systeme, sind Gegenbeispiele zu dieser Schlussfolgerung.
  • Die gesamte Finanzindustrie würde wohl nicht zustimmen. Und willst du nicht kurz aus dem Ruhestand zurückkommen und anderen Entwicklern deinen COBOL-Code erklären?
  • Mit der richtigen Infrastruktur kann so etwas durchaus weiterlaufen.
    Genauer wäre eher: „Unlesbarer Code bleibt langfristig nicht änderbar.“
  • Kein schlechter Punkt, aber eher ein anderes Thema.
    Solange es nicht um absichtliche Obfuskation geht, ist der meiste Code für jemanden lesbar, der sich die Mühe machen will, und notfalls gibt es Code-Formatter.

• Dazu kommt noch eine weitere Schlussfolgerung. Zwischen den folgenden Stufen steigt die Zahl der Nutzungen jeweils exponentiell an.

  1. Sprachdesigner und Entwickler der Standardbibliothek
  2. Entwickler gemeinsamer Module oder Bibliotheken
  3. Allgemeine Entwickler
  4. Endnutzer
     In vielen Sprachen liegt das Verhältnis zwischen den Stufen ungefähr bei dem Faktor 1000, sodass auf einen Sprachdesigner 1000 Menschen kommen können, die Module entwerfen und veröffentlichen, eine Million Entwickler und eine Milliarde Nutzer. Je nach konkreter Situation schwanken die Zahlen stark, aber für eine qualitative Diskussion stimmt die Größenordnung ungefähr.
     Der Kernpunkt ist, dass selbst kleine Nachlässigkeit auf Stufe eins oder zwei sich stromabwärts dramatisch vervielfacht. Ein schmutziger Hack, der auf Stufe 1 eine Minute „der eigenen Bequemlichkeit“ spart, kann buchstäblich Millionen Stunden wertvollen Lebens anderer Menschen verschwenden. Etwa indem sie auf langsame Software warten müssen, durch Abstürze frustriert werden oder auf Stufe 2 und 3 länger auf Features warten müssen.
     Um auf den ersten beiden Stufen das nötige Qualitätsniveau zu halten, braucht es enorme Selbstdisziplin und persönliche Ethik. Umgekehrt macht es mich jedes Mal tief traurig, wenn ich Leute Positionen verteidigen höre, die sich bei der Gestaltung von Kernsprachen oder Standardbibliotheken nicht rechtfertigen lassen.
     Man hört oft Dinge wie: „Wenn man nur die ganze Geschichte kennt, wie diese scharfe Kante entstanden ist, ist das schon okay! Wenn man für immer wachsam bleibt, ist es kein Problem. Es ist nicht unsicher, sicherheitsgefährdend, langsam oder problematisch, solange man es nur nicht falsch benutzt.“ Denn man weiß, dass genau solche Dinge über Jahrzehnte hinweg Entwickler zu Fall bringen und Software für Millionen oder Milliarden Menschen verlangsamen werden.

• Der Autor scheint aus einer ziemlich brauchbaren Faustregel eine Theorie von allem machen zu wollen.
  Das wirkt sauber und klug, aber wenn man die gezwungene Formulierung weglässt, ist es eher das Wiederkäuen weithin bekannter Binsenweisheiten.

  • theory > /dev/null
  • Ich habe „gezwungene Formulierung“ gesagt, aber man sollte sich öfter daran erinnern, dass es in dieser Branche viele Menschen gibt, die auf Englisch schreiben, obwohl Englisch nicht ihre Muttersprache ist und sie nicht in einem englischsprachigen Land leben.
    Deshalb kann die Formulierung holprig wirken.
    Und selbst wenn es „allgemein bekannte Binsenweisheiten“ sind, verknüpft dieser Artikel sie auf besonders konsistente Weise und wird so zu einem nützlichen Referenztext.
  • Ich finde auch Wert darin, Faustregeln zu variieren und durch diese Variation Dinge, die man schon zu kennen glaubte, neu zu betrachten und einzuordnen.
    Für manche ist alles daran neu, und selbst wenn es für mich nur meine Vorurteile bestätigt hat, war es eine interessante Perspektive.
  • Genauer gesagt ist es eine Theorie von allem, was in der Softwareentwicklung schiefgehen kann. Trotzdem fand ich es interessant zu lesen.
  • Hast du bis zum Ende gelesen? Der ganze Rest ist nur Hintergrundgeschichte.

• Das Framing des Autors kann auf zu viele Arten missverstanden werden, um als nützliche Kurzform zu taugen. Zwischen diesen Tokens kann es keine absolute Rangfolge geben
  Zunächst ist „dev“ hier nicht eine einzelne Person, sondern eine Gruppe von Menschen mit unterschiedlicher Expertise und Berufserfahrung aus den Produkt-, Engineering- und Design-Organisationen mehrerer Teams
  Auch „ops“ ist nicht nur eines und bedeutet nicht nur Engineering Operations. Dazu können auch Business Operations, Kundensupport usw. gehören
  „biz“ ist ebenfalls nicht nur eines. Dazu gehören Branding, Marketing, Vertrieb, Rechtsabteilung sowie Führungskräfte, Vorstand, Regulierungsbehörden, Kreditgeber und Investoren
  All diese Menschen beeinflussen, welcher Code geschrieben wird, wie er geschrieben wird und wann und wie er an Nutzer ausgeliefert wird. Alle müssen dasselbe Problem lösen
  Viele Menschen in einer Organisation existieren oft genau dafür, dass alle dasselbe Problem verstehen und sehen und auf dasselbe Ziel hinarbeiten
  Dieses Verständnis entwickelt sich jedoch ständig weiter, und es gibt Verzögerungen, bis es sich in der gesamten Organisation verbreitet. Deshalb gibt es auch Verzögerungen dabei, dass alle auf dasselbe Ziel hinarbeiten, während sich dieses Ziel selbst verändert
  Schließlich ist auch „user“ nicht nur eines, und keine Nutzergruppe ist statisch. Es gibt verschiedene Nutzergruppen, und ihr Verhalten ist langfristig möglicherweise nicht stabil
  Deshalb hilft es, zu verstehen und anzuerkennen, wie sich alle Variablen im Umfeld verändern, und in diesem Kontext eine unvollkommene und kaputte Welt zu interpretieren. Sonst verfällt man leicht in die Haltung, dass alle anderen unfähig seien und alles kaputt sei, sodass man am liebsten alles von Grund auf neu bauen würde

• Ich freue mich, dass hier etwas diskutiert wird, das nahe an Ethik heranreicht
  In der Passage „Ich glaube, es gibt eine Diskrepanz zwischen dem, was wir für gute Arbeit hielten, und dem, was ein erheblicher Teil der Branche für profitabel hält, und ich denke, das ist ein Grund für das wachsende Unbehagen vieler Software-Fachleute“ ist Unbehagen eine ziemlich schwache Formulierung. Vieles bleibt unausgesprochen
  Ich würde gern ein paar Fragen ergänzen. Was geschieht, wenn der Nutzer nicht der Kunde ist, also nicht die zahlende Person? Hat ein Unternehmen ethische Verpflichtungen gegenüber allen Nutzern, auch gegenüber nicht zahlenden? Was passiert, wenn ein zahlender Kunde Ihr Geschäft so nutzen will, dass dadurch negative nachgelagerte Effekte für die Nutzer entstehen?
  Was wäre zum Beispiel, wenn eine Plattform Betrug leichter macht als bestehende Alternativen, oder die Verbreitung von Desinformation erleichtert, oder es einfacher macht, die Meinungen von Nutzern auf langfristig zerstörerische, aber attraktive und gewohnheitsbildende Weise zu formen? All das hat sich über gewisse Zeiträume als erfolgreiches Geschäftsmodell erwiesen
  Wenn diese Dynamiken real sind, sollte ein Unternehmen dann solche ausbeuterischen Modelle verfolgen? Und wenn ja, kann es das verantwortungsvoller tun? Kann eine ethischere Version eines Geschäfts die schlimmsten Tendenzen von Wettbewerbern abmildern, oder wird man am Ende doch Teil des Problems?
  Die zentrale Schlussfolgerung ist klar. Manche Arten von Problemen sind größer und wichtiger als ein Geschäftsmodell. Es gibt Probleme, die sich so formulieren lassen: „Welche Normen und Regeln braucht es, damit Unternehmen innerhalb eines gewissen Rahmens des gesunden Menschenverstands agieren?“
  Zum Schluss möchte ich noch etwas klarstellen. Ein Unternehmen vermittelt zwangsläufig eine Reihe von Werten; das lässt sich nicht vermeiden. Selbst die Haltung „Popularität gewinnt“ ist bereits eine Entscheidung mit tiefgreifenden Implikationen für Werte. Politikwissenschaftler und Historiker kennen das Problem der Tyrannei der Mehrheit seit Langem. Unabhängig von der eigenen politischen Philosophie ist das bedenkenswert
  Ich weiß nicht, welches ethische System das „beste“ ist, aber ich weiß, dass manche Ethiken besser sind als andere. Und ich hoffe, dass wir Ethik weiter verfeinern, statt sie ungeprüft liegen zu lassen

  • Ich denke, das ist ein anderes Problem als das, von dem der Artikel spricht
    Man kann wählen, welche Probleme und Bereiche zur eigenen Ethik passen. Dieser Artikel handelt davon, wie man Systeme baut und wie man Arbeitsprioritäten festlegt

• Unternehmen existieren nicht wirklich, sondern sind imaginäre Konstrukte, die wir geschaffen haben, um Ressourcen zu organisieren und gemeinsam zu arbeiten
  Das Unternehmen ist nicht das Allerwichtigste. Es gibt viele Nutzer, und ihre Interessen stehen manchmal im Konflikt. Man kann nicht überall zugleich sein und nicht alles zugleich sein, also muss man Prioritäten setzen. Es mag so wirken, als wäre es „gut fürs Unternehmen“, profitablere Nutzer oder Nutzer zu verfolgen, die zur langfristigen Strategie passen, aber tatsächlich ist das Ziel, den Nutzern zu dienen. Es sind nur ein paar Schritte mehr dazwischen
  Wenn interne Politik so verstrickt ist, dass Entscheidungen nur noch zum Vorteil des Unternehmens getroffen werden, ohne zu hinterfragen, wie das am Ende zum Glück der Nutzer führt, dann ist die Organisation toxisch geworden. Dann sollte sie nicht weiter existieren. Sie kann zwar noch eine Weile zombiemäßig weiterwanken, ist aber im Niedergang, und die guten Leute werden alle gehen

  • Zu sagen, dass Unternehmen nicht wirklich existieren, ist ähnlich, wie zu sagen, dass Gefühle nicht existieren
    Man kann behaupten, auch Gefühle seien nur Konstrukte, die geschaffen wurden, um Reaktionen auf Situationen zu beschreiben, aber nur weil sie nicht aus Atomen bestehen, heißt das nicht, dass sie nicht „real“ sind
    Unternehmen existieren insofern, als sie der Hauptfaktor sind, der das Leben der meisten Menschen bestimmt. Sie formen Städte, Medien, Gesetze, Politik und Außenpolitik und beeinflussen fast alles Wichtige stark. Ob sie nun real sind oder nicht, sie haben konkrete Auswirkungen auf unsere Umgebung
    Außerhalb von Open Source ist ziemlich offensichtlich, dass die zahlende Seite bestimmt, was gebaut wird. Selbst wenn diese Entscheidung schlecht für diese Seite selbst, schlecht für die Nutzer und schlecht für die Allgemeinheit oder die Umwelt ist. Natürlich gibt es Branchen- und staatliche Regulierung, aber im Großen und Ganzen hat das Unternehmen die Entscheidungsgewalt
  • Das stimmt so nicht. Unternehmen existieren als rechtliche Konstrukte, und es gibt viele Dinge, die gut für Unternehmen, aber schlecht für fast alle anderen sind. Außerdem existieren Unternehmen nicht, um den Nutzern zu dienen
    Unternehmen existieren leider, um ihren Eigentümern zu dienen. In den meisten Fällen, besonders bei großen Firmen und nicht bei Kleinstbetrieben mit weniger als fünf Personen, wollen die Eigentümer Geld, also existiert jeder im Unternehmen dafür, den Eigentümern mehr Geld zu verschaffen. Das Glück anderer Menschen, selbst das der Nutzer, ist völlig irrelevant, außer soweit es mit Umsatz korreliert
    Ein weiterer universeller Anreiz innerhalb von Unternehmen ist Selbsterhalt. Deshalb berücksichtigen Entscheidungsträger neben dem Geldverdienen auch die Sicherheit ihres eigenen Arbeitsplatzes
    Mitarbeiter gehen nicht einfach. Das liegt daran, dass Unternehmen sie ausreichend zufriedenstellen. Es ist erstaunlich leicht, Menschen in einer bösen oder gesichtslosen Organisation zu halten, indem man gut bezahlt und ihnen das Gefühl gibt, Teil einer „Community“ zu sein. In FAANG-Büros kann man eine detaillierte Liste solcher HR-Tricks sehen
    Ich stimme zu, dass solche Unternehmen toxisch sind und nicht existieren sollten, aber tatsächlich funktionieren Unternehmen genau so. Das ist kein Zeichen des Verfalls, sondern das Bild eines reifen und gesunden Unternehmens, das über Jahrzehnte bestehen kann. Führungskräfte, Produkte und Eigentümer wechseln, aber das Unternehmen bleibt
  • Anfangs hatte ich dieselbe Reaktion. Wenn man einen Text sieht, der sich auf Geld > Menschen reduzieren lässt, wirkt er falsch
    Aber Wichtigkeit ist subjektiv. Wenn es um privaten Code für das eigene Vergnügen geht, ist das Unternehmen unwichtig. Wenn man daraus seine Haupteinnahmequelle machen will, ist das Unternehmen das Wichtigste. Denn wenn Software niemandem dienen kann, wird sie nie zu realem Umsatz, egal wie sehr Nutzer sie mögen
  • Lassen wir „Unternehmen“ hier großzügig als ein nachhaltiges Finanzierungsmodell verstehen, das Wartung, Support und zukünftige Entwicklung tragen kann
    Ohne Geschäftsmodell kann selbst großartige Software, die Nutzer lieben, die sich ausliefern lässt und wartbar ist, wieder verschwinden

• Anfangs war ich skeptisch, aber mir gefällt dieses Denkmodell
  Natürlich sollte man ihm nicht blind folgen. Es gibt Ausnahmen, in denen dev > biz gilt, wie bei der OpenAI-Affäre, und auch Ausnahmen, in denen dev > ops gilt. Gerade in frühen Startups muss man sich schnell bewegen, daher kann besonders aus Business-Gründen dev > ops gelten