Le code est plus souvent exécuté que lu

• Le principe selon lequel « le code est plus souvent lu qu’écrit » part de l’idée de privilégier le mainteneur plutôt que l’auteur, puis s’étend à un modèle de décision qui prend aussi en compte les utilisateurs, l’exploitation et le business
• La valeur du code ne tient pas à sa sophistication en soi, mais au fait qu’il réponde à l’objectif de l’utilisateur ; il est important de le montrer tôt et souvent aux utilisateurs, puis d’intégrer leurs retours
• « Exécuter » du code en production inclut le déploiement, les mises à niveau, l’observation, l’audit, le monitoring, les corrections et le retrait ; les coûts d’exploitation à long terme peuvent largement dépasser les inconforts rencontrés pendant le développement
• KISS ne se limite pas à simplifier le code : le principe s’étend à l’exploitation, en réduisant les pièces mobiles et en comprenant les modes de défaillance afin que le système continue de fonctionner même en cas d’échec
• Budgets, marketing, échéances, parties prenantes, investisseurs et intérêts politiques interviennent dans les décisions ; il faut donc reconnaître que satisfaire les utilisateurs et générer du chiffre d’affaires ne coïncident pas toujours

---

Élargissement du modèle de priorités

• Dire que « le code est plus souvent lu qu’écrit » signifie que la personne qui écrit le code au départ ne doit pas ignorer le coût supporté par celles et ceux qui le liront et le modifieront plus tard
• Ce principe justifie d’investir dans la maintenabilité, par exemple via la simplicité, les tests et la documentation
• En le condensant, on peut voir ce modèle comme maintainer > author

L’utilisateur passe avant le développeur

• Le code est un moyen au service d’un objectif, et un logiciel doit rendre service à un utilisateur donné
• Même le code le mieux écrit ou la technologie la plus sophistiquée perd de sa valeur s’ils ne répondent pas à l’objectif visé et n’offrent pas une bonne expérience utilisateur
• La priorité devient user > maintainer > author, ou user > dev si l’on ne distingue pas les rôles de développeur
• Plutôt que de se contenter de deviner ce que veulent les utilisateurs, ou de le leur demander, il vaut mieux mettre le programme tôt et souvent entre leurs mains et intégrer ce que l’on apprend de leurs retours

L’exécution inclut l’exploitation en production

• « Exécuter » ne signifie pas simplement lancer un programme : cela englobe tout le processus d’exploitation en production
  • Déploiement
  • Mise à niveau
  • Observation
  • Audit
  • Monitoring
  • Correction
  • Retrait
• Dans Choose Boring Technology, Dan McKinley estime que le coût à long terme du maintien d’un système en fonctionnement fiable est presque toujours bien supérieur aux désagréments rencontrés pendant sa construction
• En intégrant cette perspective, le modèle devient user > ops > dev
• Beaucoup de logiciels n’atteignent jamais une échelle de production significative et sont construits sur des hypothèses non validées
• Quand on exploite du code en production, KISS dépasse la dimension du code pour devenir un problème de réduction des pièces mobiles et de compréhension des modes de défaillance
• L’important est de déployer quelque chose et de garantir que cela continue de fonctionner même en cas d’échec

Le business est un axe distinct

• Développer en pensant aux utilisateurs permet d’aller loin, mais l’idée selon laquelle « un logiciel qui a de la valeur pour les utilisateurs a aussi de la valeur pour l’organisation » est une abstraction simplifiée
• Du point de vue du développeur, il est facile de séparer les choses ainsi : on crée un bon logiciel, et le business le transforme en argent ; mais il arrive toujours un moment où il faut intégrer une perspective business dans le travail
• Cette distinction fonctionne globalement pour les logiciels grand public comme pour les logiciels d’entreprise
• Le modèle s’étend alors à biz > user > ops > dev
• Le budget en est l’exemple le plus évident : les ressources pour satisfaire les besoins des utilisateurs n’étant pas infinies, il faut mesurer coûts et bénéfices
• Marketing, échéances, parties prenantes, investisseurs, intérêts personnels et politique influencent aussi les décisions
• Une décision peut être juste si l’on ne considère que le logiciel, l’équipe et les utilisateurs, mais ne plus l’être à l’échelle de l’organisation entière
• Parfois, il faut faire ce qui génère du chiffre d’affaires plutôt que ce qui ravit les utilisateurs

Les signaux d’alerte des organisations de développement, vus à travers le modèle

• Code impossible à maintenir : author > maintainer

  • Du code malin mais paresseux se transforme en spaghetti et en « forêt hantée »
  • Cela inclut des problèmes comme l’optimisation prématurée ou des modules que seule une personne précise peut modifier

• Logiciel inutilisable : dev > user

  • Il vient d’équipes qui n’apprennent pas des utilisateurs ou qui privilégient la technologie
  • Exemples : programmes surconçus, « modernisations » qui dégradent l’expérience utilisateur, applications web qui cassent des fonctionnalités du navigateur

• « Ça marche sur ma machine » : dev > ops

  • C’est un logiciel qui n’a pas été conçu en pensant à l’exploitation
  • Cela inclut une complexité excessive, comme utiliser une base de données sophistiquée pour une petite charge de données, ou faire exploiter un écosystème de microservices par une seule petite équipe
  • Les logiciels où la personne réveillée au milieu de la nuit en cas d’incident n’est pas celle qui les a conçus entrent aussi dans cette catégorie

• « Ce qui est juste » : dev > biz

  • C’est le cas lorsqu’on traite le code comme une fin en soi
  • Exemples : artisans prétentieux, musiciens du Titanic, Lisp Hackers

• Développement piloté par le CV : dev > *

  • C’est le logiciel produit lorsqu’il n’y a aucun enjeu et que les développeurs peuvent faire ce qu’ils veulent

• Logiciel imaginaire : biz > user > ops > dev

  • Logiciel construit, mais qui va peu, voire jamais, en production
  • Charity Majors appelle cela living a lie
  • Les logiciels sans utilisateurs relèvent aussi du logiciel imaginaire : ils ne résolvent aucun problème, résolvent le mauvais problème, ou un problème que personne n’a jamais eu
  • Cela inclut aussi les cas où l’on brandit une technologie survendue pour taper sur tout ce qui bouge jusqu’à faire émerger quelque chose qui ressemble vaguement à un cas d’usage

• « Capitalisme tardif »

  • Cas où un logiciel financé par le capital-risque n’a pas de modèle économique, ou adopte un modèle consistant à exploiter les utilisateurs après avoir atteint une position monopolistique

La tension entre utilisateurs et business

• biz > user a des conséquences difficiles à accepter
• La manière dont on apprenait le logiciel consistait à résoudre les problèmes des utilisateurs finaux, et l’un des derniers conseils de The Pragmatic Programmer se résume à ne pas simplement livrer du code, mais à ravir les utilisateurs
• À mesure que le logiciel s’est généralisé, cette hypothèse est devenue de plus en plus difficile à tenir
• Beaucoup de logiciels ne se soucient pas des utilisateurs, les manipulent ou les transforment en produit
• Ce problème ne se limite pas aux réseaux sociaux
  • Des pop-ups qui cherchent à capter l’attention de l’utilisateur apparaissent aussi lors d’une réservation de chambre, d’une commande de nourriture ou d’un clic sur le bouton Démarrer de Windows
  • Google Search est décrit comme renvoyant des résultats dignes d’un tas d’ordures
• Le décalage entre ce que beaucoup croyaient être une bonne action et ce qu’une grande partie du secteur considère comme rentable explique le malaise de nombreux professionnels du logiciel
• On ne peut pas revenir à une époque où l’on ignorait les réalités économiques, mais il faut adopter une posture éthique plus forte pour ne pas nuire aux utilisateurs
• Les utilisateurs ne peuvent pas toujours passer avant le business, mais le business ne doit pas non plus passer systématiquement en premier
  • user > ops > dev
  • biz > ops > dev
  • biz ≹ user

[GN⁺]

Avis de Hacker News

• Certains utilisateurs utilisent un système non pas parce qu’ils l’apprécient, mais parce que leur entreprise l’a acheté.
  Dans ce genre de situation, par définition, le business passe avant l’utilisateur, et les développeurs finissent par répondre aux demandes des cadres intermédiaires chez le client plutôt qu’à celles des vrais utilisateurs. Sinon, ils ne décrochent pas le contrat. Au final, les utilisateurs se retrouvent coincés avec des fonctionnalités livrées à la va-vite, pendant que l’équipe de développement est occupée à créer de nouvelles fonctions qui plairont aux cadres intermédiaires.
  C’est un peu cynique, mais en tant qu’ingénieur, il est utile de savoir si l’on travaille fondamentalement dans ce type d’entreprise. Par exemple, un détaillant en ligne est très sensible à ses utilisateurs, au point d’avoir des versions différentes de son site selon les pays parce que les Allemands aiment X et les Américains aiment Y. De petits changements peuvent faire une grosse différence sur le chiffre d’affaires.
  À l’inverse, certaines entreprises sont très peu sensibles à l’utilisabilité, parce que la personne qui achète le produit n’est pas celle qui l’utilise réellement.

  • J’ai travaillé dans une entreprise qui vendait du SaaS à de grandes entreprises.
    Pour décrocher les contrats, il fallait cocher les cases de la checklist du client, mais nous nous préoccupions aussi de l’expérience utilisateur. Une bonne expérience utilisateur faisait rarement partie des exigences strictes du client.
    Les logiciels concurrents étaient extrêmement pénibles à utiliser, donc nous voulions nous différencier là-dessus ; cela rendait la formation plus simple, les utilisateurs plus satisfaits, et quand c’était possible, ils recommandaient à leurs responsables d’acheter davantage de notre produit.
    Au fond, c’était à 80 % une question de fierté et d’empathie — « notre logiciel n’est pas nul » — mais à long terme, c’était aussi dans notre intérêt, parce que cela construisait notre marque.
  • J’ai travaillé dans une entreprise sur un marché avec une structure d’achat similaire, et nous nous concentrions uniquement sur les utilisateurs.
    Nous avions adopté une stratégie de croissance tirée par le produit, sans commerciaux, et l’équipe produit se concentrait entièrement sur l’expérience utilisateur. Le problème, c’est que nous ne vendions pas aux utilisateurs. Les personnes qui achetaient le logiciel étaient d’autres personnes au sein de l’organisation utilisatrice, et elles n’avaient même pas d’expérience directe du produit.
    C’était une approche vouée à l’échec. Il nous fallait des commerciaux capables de comprendre ce que les acheteurs avaient en tête, de leur expliquer les bénéfices, et de coacher les utilisateurs pour qu’ils puissent expliquer ces bénéfices à d’autres personnes dans leur organisation. Il fallait combler l’écart entre utilisateurs et acheteurs.
  • En général, les cadres intermédiaires sont aussi des utilisateurs, mais ils ne représentent qu’une petite partie de la base d’utilisateurs, et les fonctionnalités qu’ils utilisent sont différentes, comme les rapports.
    La question devient donc de savoir quels utilisateurs prioriser, et de trouver un équilibre entre privilégier l’expérience d’une minorité qui a de l’influence sur les autres utilisateurs, et maintenir le produit suffisamment utilisable pour que les autres utilisateurs fournissent des données utiles à la direction.
  • J’ai vécu cela dans une entreprise qui vendait des logiciels à des municipalités.
    Tout ce qui comptait, c’étaient les avis du maire, du directeur municipal et du conseil municipal. Si les rapports avaient bonne apparence et que le prix convenait, ils renouvelaient.
    Je me souviens de réunions sur le terrain où les personnes qui utilisaient le logiciel tous les jours nous disaient en face à quel point il était horrible. Et pourtant, sans exception, avec la promesse de corriger quelques bugs précis et une hausse de prix minimale, ce client renouvelait.
  • Le fait que les développeurs finissent par répondre aux demandes des cadres intermédiaires chez le client plutôt qu’à celles des vrais utilisateurs est la raison pour laquelle les logiciels d’entreprise sont globalement mauvais.

• Aujourd’hui, j’ai découvert le symbole ≹. Il « indique une relation dans laquelle, entre deux éléments comparés, aucun n’est ni supérieur ni inférieur à l’autre, sans qu’on puisse nécessairement dire qu’ils sont égaux. C’est une nuance importante dans les domaines où il existe des modes de comparaison qui ne sont pas strictement numériques » (https://www.mathematics-monster.com/symbols/Neither-Greater-...)

  • L’exemple avec des nombres complexes z_1, z_2 où l’on écrit z_1 ≹ z_2 est étrange.
    Il me semblerait plus clair d’écrire plutôt |z_1| = |z_2|, c’est-à-dire que les deux nombres complexes ont la même valeur absolue.
    Le texte dit : « En conclusion, le symbole ≹ joue un rôle important en fournissant une zone intermédiaire entre les opérateurs relationnels traditionnels », mais en tant que doctorant en mathématiques, je ne l’ai jamais vu. J’ai du mal à croire qu’il joue un rôle important.
  • Ce glyphe devrait être le résultat de la combinaison de l’emoji pomme et de l’emoji orange.
  • Cela me fait penser à la notion de jeu en théorie des jeux combinatoires.
    Les jeux forment un sur-ensemble des nombres surréels, et les nombres surréels un sur-ensemble des nombres réels ; on assouplit la définition des surréels, ce qui fait perdre la propriété d’ordre total.
    On obtient ainsi des nombres étranges qui peuvent être « confondus » avec d’autres, ou qui sont « flous ». L’exemple le plus simple est * (star), qui n’est ni supérieur ni inférieur à 0 et se confond donc avec 0. C’est comme un nuage flou autour de 0, et on le note 0║*.
    Un jeu plus complexe, le switch, peut être confondu avec un intervalle de nombres plus grand et est considéré comme « chaud ». En construisant des nombres avec des switches, on peut créer des jeux chauds plus intéressants.
  • Je pense que ce concept est important pour comprendre l’ordre causal dans les systèmes distribués. Par exemple dans le contexte des CRDT.
    Les événements générés sur un seul appareil ont toujours un ordre complet. Mais si deux appareils hors ligne génèrent des événements, on ne peut pas dire lequel est venu en premier, et il existe une relation ≹ entre les deux événements. Autrement dit, on considère que les événements sont simultanés.
    On peut donc avoir les ordres « d > b > a » et « d > c > a », mais « c ≹ b ».
    Définir une manière déterministe de résoudre les égalités dans ce type de cas est une grande partie du problème que les CRDT cherchent à résoudre.
  • Dans le lien, l’« exemple 1 : contexte numérique » prend deux nombres réels a et b, et dit que si a n’est ni supérieur ni inférieur à b, sans être explicitement égal à b, alors la relation est ≹.
    Comment est-ce possible ?

• Pour beaucoup d’entre nous, le coût d’exécuter du code un milliard de fois peut être inférieur à quelques minutes du temps d’un développeur
  Si je dépense 200 dollars par mois en serveurs chez AWS, je peux exécuter une bonne partie du code de mon API web même 100 milliards de fois
  Donc optimiser pour les lecteurs humains est toujours préférable, et il ne faut faire d’autres optimisations que lorsqu’il est prouvé que c’est d’une lenteur économiquement intenable

  • L’auteur semble penser la même chose, mais avoir choisi un titre déroutant
    L’article se termine ainsi :
    user > ops > dev
    biz > ops > dev
    biz ≹ user
    La conclusion semble plutôt être que le code existe pour les utilisateurs finaux et pour le business. Le dernier symbole, ≹, exprime élégamment que les besoins des utilisateurs finaux et ceux du business ne sont pas identiques, mais qu’ils sont tous deux aussi importants pour l’existence du code
  • Le problème avec le calcul « cela coûte moins cher que le temps d’un développeur », c’est que, en général, celui qui paie ce coût n’est pas vous
    Les utilisateurs paient de manière moins évidente : facture d’électricité plus élevée, durée de vie réduite[0], occasions perdues, frustration accrue, renouvellements matériels plus fréquents
    De plus, la plupart des utilisateurs n’ont ni le salaire ni la qualité de vie d’un développeur, donc le préjudice leur paraît plusieurs fois plus lourd
    [0] Gaspiller le temps d’autrui, c’est réduire des QALY
  • Dans l’article, « exécution » ne signifie pas simplement lancer un programme
    Il dit que cela inclut l’exploitation en production, c’est-à-dire le déploiement, les mises à niveau, l’observation, l’audit, la supervision, les corrections, la mise au rebut, etc.
  • D’après mon expérience, il faut se soucier de la latence, parce qu’elle affecte l’expérience utilisateur. Acheter une meilleure latence avec de l’argent est assez difficile
  • C’est à ce type de réaction que je m’attendais en lisant le titre. Mais cet article est autre chose. Il vaut la peine d’être lu

• Si l’on reformule la conséquence du titre à l’auteur, ce n’est pas tant « le code est lu plus souvent qu’il n’est écrit », mais plutôt un code illisible ne peut pas tourner longtemps
  Cela dit, je suis un administrateur système expérimenté qui cherche à bifurquer vers le développement, donc en ce sens je suis un complet débutant

  • Il y a énormément de code fossilisé que les gens ont peur de toucher parce qu’ils ne le comprennent pas, mais dont dépend le business
  • Les logiciels propriétaires sans sources, par exemple les bibliothèques tierces ou presque tous les systèmes boîtes noires, sont des contre-exemples à cette conclusion
  • Toute l’industrie financière ne serait probablement pas d’accord. Et vous n’envisagez pas de sortir brièvement de votre retraite pour expliquer votre code COBOL aux autres développeurs ?
  • Avec la bonne infrastructure, je pense qu’il peut continuer à tourner
    Plus précisément, ce serait plutôt : « un code illisible ne reste pas modifiable longtemps »
  • Ce n’est pas un mauvais point, mais cela relève plutôt d’un autre sujet
    Sauf si l’on parle d’obfuscation volontaire, la plupart du code peut être lu par quelqu’un qui a envie de faire l’effort, et il existe aussi des formateurs de code si nécessaire

• Il y a une conséquence à ajouter ici. Entre chacune des étapes suivantes, le nombre d’utilisations augmente exponentiellement

  1. Concepteurs de langages et développeurs de bibliothèques standard
  2. Développeurs de modules ou de bibliothèques partagés
  3. Développeurs ordinaires
  4. Utilisateurs finaux
     Dans beaucoup de langages, le ratio à chaque étape est de l’ordre de 1000 : pour un concepteur de langage, il peut y avoir 1000 personnes qui conçoivent et publient des modules, un million de développeurs et un milliard d’utilisateurs. Les chiffres précis varient fortement selon le contexte, mais l’ordre de grandeur est à peu près juste pour une discussion qualitative
     Le point essentiel est qu’une toute petite paresse au premier ou au deuxième niveau se multiplie de façon spectaculaire en aval. Un sale hack créé au niveau 1 pour économiser une minute « par confort personnel » peut littéralement faire perdre des millions d’heures de vie précieuse à d’autres personnes : en les faisant attendre devant un logiciel lent, en les frustrant avec des plantages, ou en retardant le développement de fonctionnalités aux niveaux 2 et 3
     Maintenir le niveau de qualité nécessaire aux deux premiers niveaux exige une discipline personnelle et une éthique individuelle considérables. À l’inverse, je suis profondément attristé chaque fois que j’entends quelqu’un défendre des positions injustifiables sur la conception de langages fondamentaux ou de bibliothèques standard
     On entend souvent des choses comme : « ce bord tranchant ne pose pas de problème si l’on connaît toute l’histoire de son apparition ! Ce n’est pas un problème si l’on reste vigilant pour toujours. Ce n’est ni dangereux, ni risqué pour la sécurité, ni lent, ni problématique tant qu’on ne l’utilise pas mal », parce que je sais que ces choses feront trébucher des développeurs pendant des décennies et ralentiront les logiciels de millions ou de milliards de personnes

• L’auteur semble prendre une règle empirique plutôt correcte pour en faire une théorie du tout
  Cela a l’air propre et sage, mais une fois les formulations forcées retirées, cela ressemble surtout à une ressassement de banalités bien connues

  • theory > /dev/null
  • J’ai parlé de « formulations forcées », mais il faut souvent se rappeler que, dans ce secteur, beaucoup de gens écrivent en anglais sans être anglophones natifs ni vivre dans un pays anglophone
    Les tournures peuvent donc être maladroites
    Et même s’il s’agit de « banalités bien connues », cet article les relie d’une manière particulièrement cohérente, ce qui en fait une référence utile
  • Je pense qu’il y a aussi de la valeur à décliner une règle empirique et, à travers cette déclinaison, à revoir et contextualiser des choses que l’on pensait déjà savoir
    Pour quelqu’un, tout cela sera nouveau, et même si ce n’était pour moi qu’une confirmation de mes biais, c’était un point de vue intéressant
  • Plus précisément, c’est une théorie du tout de tout ce qui peut mal tourner dans le développement logiciel. Je l’ai tout de même trouvé intéressant à lire
  • Tu l’as lu jusqu’au bout ? Tout le reste n’est que contexte

• Le cadrage de l’auteur peut être mal compris de trop nombreuses façons pour constituer une abréviation utile. Il ne peut pas y avoir de hiérarchie absolue entre ces tokens
  D’abord, ici, « dev » ne désigne pas une personne, mais un ensemble de personnes aux expertises et niveaux d’expérience variés, réparties entre les organisations produit, ingénierie et design de plusieurs organisations
  « ops » n’est pas non plus une seule chose, et ne signifie pas seulement opérations d’ingénierie. Cela peut aussi inclure les opérations métier, le support client, etc.
  « biz » n’est pas non plus une seule chose. Il y a le branding, le marketing, les ventes, le juridique, ainsi que la direction, le conseil d’administration, les régulateurs, les prêteurs, les investisseurs, etc.
  Toutes ces personnes influencent le code qui est écrit, la manière dont il est écrit, et quand et comment il est déployé auprès des utilisateurs. Tout le monde doit résoudre le même problème
  Dans une organisation, beaucoup de personnes existent souvent pour faire en sorte que tout le monde comprenne et voie le même problème, et travaille vers le même objectif
  Mais cette compréhension évolue en permanence, et il y a un délai avant qu’elle se diffuse dans toute l’organisation. Il y a donc aussi un délai pour que tout le monde travaille vers le même objectif alors que l’objectif lui-même est en train de changer
  Enfin, « user » n’est pas non plus une seule chose, et aucun groupe d’utilisateurs n’est statique. Il existe divers groupes d’utilisateurs, dont les comportements peuvent ne pas être stables à long terme
  Il est donc utile de comprendre et de reconnaître comment toutes les variables autour de soi évoluent, puis d’interpréter, dans ce contexte, un monde imparfait et cassé. Sinon, on tombe facilement dans l’idée que tous les autres sont nuls, que tout est cassé, et qu’il faudrait tout reconstruire depuis zéro

• Je suis content de voir que des sujets proches de l’éthique sont discutés
  Dans le passage du texte disant : « il y a un décalage entre ce que nous pensions être faire le bien et ce qu’une grande partie du secteur considère comme rentable, et je pense que c’est la raison du malaise croissant de nombreux professionnels du logiciel », le mot malaise est une formulation assez faible. Beaucoup de choses restent non dites
  J’aimerais ajouter quelques questions. Que se passe-t-il quand l’utilisateur n’est pas le client, c’est-à-dire la personne qui paie ? Une entreprise a-t-elle des obligations éthiques envers tous les utilisateurs, y compris ceux qui ne paient pas ? Que se passe-t-il si un client payant veut utiliser votre activité d’une manière qui crée des effets négatifs en aval pour les utilisateurs ?
  Par exemple, que se passe-t-il si une plateforme rend les arnaques plus faciles que les alternatives existantes, facilite la diffusion de fausses informations, ou facilite le shaping des opinions des utilisateurs d’une manière destructrice à long terme, mais attirante et génératrice d’habitudes ? Tout cela s’est déjà révélé être, pendant un certain temps, un modèle économique performant
  Si ces dynamiques sont réelles, une entreprise doit-elle poursuivre de tels modèles d’exploitation ? Si elle le fait, peut-elle le faire de manière plus responsable ? Une version plus éthique de cette activité peut-elle atténuer les pires tendances des concurrents, ou finit-elle par faire partie du problème ?
  La conclusion centrale est claire. Certains types de problèmes sont plus grands et plus importants qu’un modèle économique. Il existe des problèmes qu’on peut formuler ainsi : « quelles normes et règles faut-il pour que les entreprises opèrent dans un certain cadre de bon sens ? »
  Enfin, je voudrais clarifier un point. Une entreprise véhicule intrinsèquement un ensemble de valeurs, et c’est inévitable. Même adopter simplement la position « ce qui est populaire l’emporte » est en soi un choix lourd d’implications en matière de valeurs. Les politologues et les historiens connaissent depuis longtemps le problème de la tyrannie de la majorité. Quelle que soit votre philosophie politique, cela mérite réflexion
  Je ne sais pas quel est le « meilleur » système éthique, mais je sais que certaines éthiques valent mieux que d’autres. Et j’espère que nous continuerons à affiner notre éthique, plutôt que de la laisser non examinée

  • Je pense que c’est un problème différent de celui dont parle l’article
    On peut choisir quels problèmes et quels domaines correspondent à sa propre éthique. Cet article parle de la manière de construire des systèmes et de prioriser le travail

• Une entreprise n’existe pas réellement : c’est une construction imaginaire que nous avons inventée pour organiser des ressources et travailler ensemble
  L’entreprise n’est pas ce qu’il y a de plus important. Les utilisateurs sont nombreux et leurs intérêts entrent parfois en conflit. On ne peut pas être partout ni être tout pour tout le monde, il faut donc établir des priorités. Chercher les utilisateurs les plus rentables, ou ceux qui correspondent à une stratégie de long terme, peut sembler « bon pour le business », mais en réalité l’objectif est de servir les utilisateurs. Il y a simplement quelques étapes intermédiaires en plus
  Quand la politique interne s’envenime au point que les décisions sont prises uniquement dans l’intérêt de l’entreprise, sans se demander comment cela se traduit en bonheur pour les utilisateurs, l’organisation est devenue toxique. Elle ne devrait plus exister. Elle peut tituber quelque temps en mode zombie, mais elle est sur une pente descendante, et toutes les bonnes personnes partiront

  • Dire qu’une entreprise n’existe pas réellement, c’est un peu comme dire que les émotions n’existent pas
    On peut bien dire que les émotions ne sont qu’une construction créée pour décrire des réactions à des situations, mais ce n’est pas parce qu’elles ne sont pas faites d’atomes qu’elles ne sont pas « réelles »
    Les entreprises existent dans la mesure où elles sont l’un des principaux facteurs qui déterminent la vie de la plupart des gens. Elles façonnent les villes, les médias, le droit, la politique, la politique étrangère, et ont une influence majeure sur presque tout ce qui compte. Réelles ou non, elles ont des effets concrets autour de nous
    En dehors de l’open source, il est assez évident que celui qui paie décide de la manière dont les choses sont construites. Même si cette décision est mauvaise pour lui, pour les utilisateurs, pour le grand public ou pour l’environnement. Bien sûr, il existe des secteurs et des réglementations publiques, mais dans l’ensemble, c’est l’entreprise qui détient le pouvoir de décision
  • Ce n’est pas vrai. Une entreprise existe comme construction juridique, et il y a beaucoup de choses qui sont bonnes pour l’entreprise mais mauvaises pour presque tout le monde. De plus, une entreprise n’existe pas pour servir ses utilisateurs
    Malheureusement, une entreprise existe pour servir ses propriétaires. Dans la plupart des cas, surtout dans les grandes entreprises qui ne sont pas de toutes petites structures de moins de cinq personnes, les propriétaires veulent de l’argent ; donc tout le monde dans l’entreprise existe pour leur en rapporter davantage. Le bonheur des autres, même celui des utilisateurs, n’a strictement aucune importance, sauf lorsqu’il est corrélé au chiffre d’affaires
    Une autre incitation universelle au sein d’une entreprise est l’autoconservation. Les décideurs prennent donc aussi en compte la sécurité de leur propre poste, en plus du fait de gagner de l’argent
    Les employés ne partent pas. L’entreprise les rend suffisamment satisfaits. En les payant bien et en leur donnant le sentiment de faire partie d’une « communauté », il est étonnamment facile de faire continuer à travailler des gens pour une organisation mauvaise ou sans visage. Les bureaux des FAANG offrent un catalogue détaillé de ce genre d’astuces RH
    Je suis d’accord pour dire que ces entreprises sont toxiques et ne devraient pas exister, mais en pratique c’est ainsi qu’elles fonctionnent. Ce n’est pas un signe de déclin, mais l’image d’une entreprise mûre et saine qui peut durer des décennies. Les dirigeants, les produits et les propriétaires changent, mais l’entreprise reste
  • Au début, j’ai eu la même réaction. Quand on voit un texte qui peut se résumer à argent > personnes, ça paraît faux
    Mais l’importance est subjective. Si c’est du code personnel écrit pour son propre plaisir, le business n’a pas d’importance. Si l’on veut en faire sa principale source de revenus, le business devient le plus important. Car si le logiciel ne sert personne, même si les utilisateurs l’adorent, cela ne se transformera pas en chiffre d’affaires réel
  • Interprétons ici généreusement « business » comme un modèle de financement durable capable de soutenir la maintenance, le support et les développements futurs
    Sans modèle économique, même un excellent logiciel apprécié des utilisateurs, distribuable et maintenable, peut finir par s’éteindre

• J’étais sceptique au début, mais ce modèle de pensée me plaît
  Bien sûr, il ne faut pas le suivre aveuglément. Il existe des exceptions où dev > biz, comme l’affaire OpenAI, et des exceptions où dev > ops. Dans une startup en phase initiale, il faut avancer vite ; le business peut donc notamment faire que dev > ops