Mon étoile polaire logicielle

Priorités en développement logiciel

1. Un logiciel doit être utile à l’utilisateur final et viser à devenir un « logiciel qu’on peut aimer »
2. Un logiciel doit être correct. Un logiciel qui dysfonctionne réduit l’utilité que l’utilisateur peut en tirer
3. Un logiciel doit être maintenable et efficace. C’est un critère pour éviter de gaspiller des ressources humaines et informatiques lorsqu’on cherche à extraire davantage d’utilité d’un logiciel

L’absurdité quand les priorités sont inversées

• Même si une blockchain n’a aucun bug, cela ne signifie rien si c’est un rugpull
• Même si le langage utilisé est memory-safe, cela ne signifie rien s’il n’y a pas de conception orientée vers la correction ni de processus pour corriger tous les bugs au fil du temps
• Même si un logiciel repose sur un magnifique canopy of abstractions, cela ne signifie rien s’il fonctionne mal et que personne ne peut le maintenir ou y ajouter de nouvelles fonctionnalités

Parfois je me décourage, parfois je m’engage sur la mauvaise voie, et parfois je fais volontairement un détour, mais personne ne peut me faire prendre ma véritable destination pour quelque chose de moindre.
J’accorde de l’importance à mon expérience de développeur, mais seulement dans la mesure où elle m’aide à produire davantage de logiciels que d’autres personnes, vous compris, peuvent apprécier.

• Le but ultime est de maximiser l’utilité pour l’utilisateur final, et tout le reste n’est qu’un moyen d’atteindre cet objectif
  • C’est le principe le plus important dans le développement logiciel

[GN⁺]

Réactions sur Lobste.rs

• Je préfère une approche similaire
  Même des outils peu « attachants » comme un tournevis peuvent rester très fiables pendant très longtemps. Un tournevis cruciforme a toujours une tête cruciforme ; il n’y a pas 1 % de chances qu’en le sortant de la boîte à outils il se soit transformé en tournevis plat et qu’il faille le ranger puis en reprendre un autre. Le design du manche ne change pas sans fin non plus, et on peut simplement utiliser l’outil qu’on a acheté jusqu’à ce qu’il casse
  J’aimerais que davantage de logiciels soient comme ça

  • Je me demande ce que signifie « des outils peu attachants comme un tournevis »

• Je respecte et j’apprécie les développeurs qui s’en tiennent au principe selon lequel « le but ultime est de maximiser l’utilité pour l’utilisateur final, et tout le reste est au service de cet objectif », mais je n’arrive pas moi-même à vivre ainsi en permanence. Je pense que, dans le logiciel, il existe d’autres responsabilités légitimes que celle envers l’utilisateur final
  Professionnellement, je développe des logiciels pour faire vivre ma famille, et même si je prends assez souvent le parti des utilisateurs, ma loyauté va au final davantage à l’entreprise qui paie et à ma famille.
  Dans mes projets personnels, mon critère est : « est-ce que ce travail m’apporte quelque chose ? », et la satisfaction artistique, esthétique et intellectuelle compte beaucoup. En général, cela va dans le sens de l’intérêt des utilisateurs, mais il se peut aussi que j’évalue mal leur utilité ; et même s’il était prouvé, par exemple, qu’un menu hamburger animé maximise cette utilité, j’estime pouvoir exercer dans mes créations mon choix esthétique et renoncer à cette utilité

  • En plus, indépendamment de ces compromis, il n’est pas toujours possible de définir clairement qui est le véritable utilisateur final
    Il y a aussi la question de savoir comment considérer les cas où l’on rend volontairement une partie du logiciel peu conviviale pour l’utilisateur, afin d’empêcher cet utilisateur de faire des choses absurdes qui nuisent aux utilisateurs de son propre travail.
    J’ai déjà discuté de l’ajout délibéré de ce type de mécanisme pour qu’une certaine fonction de reporting, très vulnérable à la loi de Goodhart et dont les effets secondaires peuvent être très étendus, reste éternellement à l’état de « pas encore disponible », même si les utilisateurs du logiciel la réclament

• C’est en voyant cet article que j’ai appris que Tiger Style avait désormais un site web

• On parle à la fois de « quelque chose que personne ne peut maintenir, et encore moins enrichir avec de nouvelles fonctionnalités » et de « corriger tous les bugs », mais au final je ne vois pas bien comment il serait possible de corriger tous les bugs sans gel du périmètre

• La phrase « même sans bug dans la blockchain, ça ne sert à rien si c’est un rug pull » permet de faire tenir trois idées en une seule
  Améliorer l’efficacité de quelque chose ne sert à rien si cela crée de nouveaux bugs, et cela n’a de sens que si ce n’est pas en plus un rug pull

• Ce qui m’a marqué, c’est qu’il n’y a nulle part l’exigence que le logiciel doive forcément être écrit uniquement par des humains. Je sais que Kristoff est un développeur central de Ziglang, ce qui rend ça encore plus intéressant
  J’aimerais croire qu’on peut, même avec du développement assisté par l’IA, produire des logiciels qui répondent à cette exigence.
  J’aime écrire le code moi-même à la main, et j’aime aussi terminer les choses, mais les deux entrent parfois en conflit.
  Désolé de ramener l’IA sur le tapis, mais entre la relation étroite entre Kristoff et la communauté Zig, les positions affirmées de Zig, et le fait que de toute façon je continue à évangéliser Ziglang, il est difficile de séparer les sujets

  • Je pense au contraire que le troisième point suggère plutôt une opposition à ce genre d’outils. Ce qu’ils produisent ressemble le plus souvent à du code spaghetti impossible à maintenir
  • Il y a sans doute une raison pour laquelle ce texte a été publié sur le blog personnel de Loris et non sur ziglang.org
    Le fait qu’un projet ait une position claire sur le code fondé sur les grands modèles de langage ne signifie pas que tous les membres de ce projet partagent la même position, ni pour ce projet ni pour tous les autres.
    Et cela ne concerne pas seulement Loris personnellement : pour ce type de décision, une évaluation au cas par cas est raisonnable