Nous sommes en train de casser le logiciel

• Nous cassons le logiciel en ne tenant plus compte de la complexité lorsque nous ajoutons des fonctionnalités ou optimisons certaines parties
• Nous cassons le logiciel avec des systèmes de build complexes
• Nous cassons le logiciel en rendant tout boursouflé et fragile avec des chaînes de dépendances absurdes
• Nous cassons le logiciel en disant aux nouveaux programmeurs : « Don’t reinvent the wheel! ». Pourtant, réinventer la roue est une manière d’apprendre comment les choses fonctionnent, ainsi que la première étape pour créer une nouvelle roue, différente
• Nous cassons le logiciel en ne tenant plus compte de la rétrocompatibilité des API
• Nous cassons le logiciel en poussant à réécrire des choses qui fonctionnent déjà
• Nous cassons le logiciel en nous jetant sur chaque nouveau langage, paradigme ou framework qui apparaît
• Nous cassons le logiciel en sous-estimant toujours la difficulté de manipuler des bibliothèques existantes complexes par rapport à une implémentation directe
• Nous cassons le logiciel en considérant que le standard de facto de XYZ est toujours meilleur que ce que nous pourrions implémenter nous-mêmes pour notre cas d’usage précis
• Nous cassons le logiciel en affirmant que les commentaires de code sont inutiles
• Nous cassons le logiciel en prenant à tort le logiciel pour une discipline purement d’ingénierie
• Nous cassons le logiciel en construisant des systèmes qu’il n’est plus possible de réduire : dans n’importe quel système, ce qui est simple devrait pouvoir être accompli simplement
• Nous cassons le logiciel en cherchant à produire du code le plus vite possible, sans faire l’effort de concevoir un code aussi bien pensé que possible
• Nous cassons le logiciel, et ce qui restera n’offrira plus le plaisir du hacking

[dohyun682]

Réinventer la roue <-> réinventer ce qui est déjà en train d’être écrit

Ces deux notions ne sont-elles pas complètement opposées l’une à l’autre ?

[roxie]

La vague des commentaires arrive

[tujuc]

Je compatis, haha. À chaque fois que de nouveaux juniors arrivent… je me demande comment leur transmettre ça. Ça pourrait être une bonne méthode..

[ilikeall]

Arrêtez de frapper, s’il vous plaît TT

[bus710]

....Je vais simplement rester tranquille...

[laeyoung]

Cela rappelle beaucoup les « dix signes avant-coureurs de la chute d’un pays » évoqués par Han Feizi.

[GN⁺]

Commentaire Hacker News

• Cela rappelle une conférence de Jonathan Blow. Le logiciel, s’il n’est pas entretenu, se dégrade comme tout le reste

  • Les technologies logicielles semblent progresser en apparence, mais en réalité elles sont en déclin
  • Les améliorations matérielles et les progrès du machine learning donnent une illusion de progrès, mais la robustesse et la fiabilité fondamentales des logiciels se détériorent
  • Le développement logiciel moderne est devenu inutilement complexe, au point de rendre difficiles même les tâches simples
  • Cette complexité réduit la productivité des programmeurs et entrave la transmission des connaissances entre les générations
  • La société finit par accepter comme normal un logiciel truffé de bugs et peu fiable
  • Si nous ne simplifions pas les systèmes logiciels à tous les niveaux, des systèmes d’exploitation aux outils de développement, la civilisation risque une régression technique comparable à des effondrements historiques

• Cela rappelle les « 10 principes du bon design » de Dieter Rams

  • Un bon design est innovant
  • Un bon design rend le produit utile
  • Un bon design est esthétique
  • Un bon design rend le produit facile à comprendre
  • Un bon design est discret
  • Un bon design est honnête
  • Un bon design dure dans le temps
  • Un bon design est rigoureux jusque dans le moindre détail
  • Un bon design est respectueux de l’environnement
  • Un bon design, c’est aussi peu de design que possible

• Partage d’une expérience de travail en entreprise dans les années 2000

  • Le travail s’effectuait sur plusieurs dizaines d’ordinateurs, avec mise en place d’une salle serveur et d’un SAN capable de stocker 3 To de données
  • Un ordonnanceur de tâches maison en VB6 coordonnait les travaux entre machines en exécutant des scripts Object Rexx
  • Des équilibreurs de charge internes, serveurs web, serveurs mail et serveurs FTP servaient à envoyer et recevoir des fichiers, avec des logiciels développés en interne
  • Aujourd’hui, l’ensemble de la configuration peut être reproduit en moins d’une semaine avec des fichiers yaml et des services cloud
  • L’architecture serveur a été « abstraite »
  • Critique de la rétrocompatibilité, présentée comme l’un des problèmes de Windows
  • Apple a cassé la rétrocompatibilité, changé cinq fois de processeur et supprimé la compatibilité avec le code 32 bits sur les puces ARM

• Beaucoup d’avis divergents

  • Il faut préserver la rétrocompatibilité tout en évitant la complexité
  • Il faut éviter les énormes arbres de dépendances et réinventer soi-même la roue
  • La seule façon de satisfaire toutes les exigences serait que plus personne n’écrive de code
  • C’est un souhait qui traverse l’esprit une fois par jour, mais ce n’est pas une fierté

• Partage d’une expérience du premier emploi

  • Le logiciel était écrit en C, la seule langue dans laquelle il semblait réaliste d’écrire du logiciel commercial
  • Une seule personne savait produire un build, avec un outil de build commercial, et c’était aussi la seule à savoir utiliser cet outil
  • Les builds prenaient plusieurs heures
  • Nous pensions bien faire

• Avis sur les raisons pour lesquelles on détruit le logiciel

  • Nous détruisons le logiciel en pensant toujours que le standard de fait de XYZ vaut mieux qu’une solution adaptée à nos besoins
  • Une approche générique permet de basculer facilement entre des solutions superficielles à de nombreux problèmes
  • Les ingénieurs aiment cette approche, surtout parce qu’ils changent souvent d’emploi et en emportent quelques-unes avec eux
  • Pourtant, les solutions sur mesure offrent souvent des performances bien supérieures aux solutions génériques

• Chaque affirmation est un compromis

  • Dans tous les cas, on sacrifie quelque chose pour obtenir autre chose
  • Parfois, il est raisonnable de ne pas réinventer la roue
  • Parfois, il faut réinventer la roue pour apprendre
  • Globalement, nous créons plus que nous ne détruisons
  • Il n’y a pas besoin d’adopter une position négative

• J’admire antirez, mais ce billet me semble rempli de formules courtes qui sonnent bien sans tenir dans une discussion approfondie

  • Exemple : les débutants ne devraient pas réinventer la roue
  • Ils devraient utiliser les outils disponibles dans le contexte donné
  • S’ils veulent expérimenter, ils devraient écrire leur propre compilateur
  • Mais ils ne devraient pas l’utiliser en production
  • La compatibilité rétroactive des API est, dans la plupart des cas, une décision business
  • Commencer chaque phrase par « nous détruisons le logiciel » n’aide pas
  • Cela sonne bien plus sombre que la réalité

• Avis sur les graphes de complexité et de dépendances

  • Le graphe de complexité/dépendances d’une application prise au hasard est absolument délirant
  • Il n’inclut pas le firmware ni l’OS, mais on n’en est pas loin
  • Il faut résoudre le problème des dépendances transitives
  • L’OS (API Win32, appels système Linux) est considéré comme la seule dépendance dure de tout ce qui est écrit en C
  • En passant à Java/Python, cette couche n’est plus contrôlable
  • Il est parfois nécessaire d’écrire quelques centaines de lignes de code adaptées à une situation précise plutôt que de dépendre de toutes les bibliothèques
  • La charge de maintenance augmente, mais les dépendances demandent elles aussi de la maintenance
  • Elles peuvent avoir de mauvaises API, casser la compatibilité de façon arbitraire, être abandonnées ou se transformer en malware
  • La taille maximale personnelle pour un projet utile est de 5 à 10 KLOC en Java/JS/Python
  • Cela peut être relu en quelques heures et modifié facilement même des années plus tard

• Éléments qui détruisent le logiciel

  • Les entretiens type Leetcode, le développement dicté par le CV, les changements d’emploi fréquents, l’arnaque de l’investissement de croissance, le jeu des métriques, la course à la promotion, le théâtre des sprints, et le baratin à tous les niveaux de l’organigramme, ainsi que l’apathie de l’industrie