Ça n'est pas quand même un appel à accumuler de la dette technique? Les bugs d'interface, ça existe, et ça impose que tout le monde dans les dizaines d'années qui vont suivre vont devoir se taper le même bug, la même lecture de la doc, la même procédure d'essais et erreurs, pour finalement se rendre compte qu'en effet il y a un bug d'interface. Tout ça c'est aussi du temps perdu pour plein d'utilisateurs, et il n'est pas du tout garanti qu'à force, ce temps ne soit pas supérieur au temps nécessaire pour corriger le problème dans les logiciels qui "exploitent" le bug au moment du changement de version.
Par exemple, dans l'exemple cité, il me semble assez évident que l'erreur est de ne pas afficher l'identifiant de l'erreur ("MaxBytesError") mais seulement sa description en anglais ("http: request body too large"). Comment tu fais pour l'internationalisation? Comment tu fais si tu t'aperçois que le texte ne couvre pas tous les cas (par exemple "request body too large or insufficient memory"?). Laisser ça intouchable, c'est admettre que ce bout de code ne peut pas être amélioré.
Ça n'est pas quand même un appel à accumuler de la dette technique?
Si tu lis la page canonique sur le sujet ainsi que le chapitre associé dans le SWE Book, tu peux voir que l'idée c'est pas d'appeler à accumuler de la dette technique de manière indiscriminée mais que, si tu as beaucoup d'utilisateurs, payer ta dette technique peut rapidement coûter cher.
En fait, j'ai quand même l'impression qu'il y deux niveaux dans cette discussion:
1) La loi d'Hyrum dit que les utilisateurs vont être amenés à utiliser plus ou moins consciemment les propriétés concrètes de l'implémentation des API qui ne font pas partie de leur abstraction.
2) Cette loi est utilisée comme raison pour limiter les changements dans l'implémentation des API.
Le deuxième point n'est pas une constatation, c'est une décision de développement qu'on peut trouver discutable. Elle part du principe que l'équipe de développement est au service des utilisateurs (c'est douteux), elle part aussi du principe que les devs ont une forme de responsabilité vis-à-vis de la manière dont les utilisateurs exploitent les fonctionnalités des logiciels (là aussi, c'est douteux). Bien sûr, c'est pragmatique, et il y a plein de raisons pour lesquelles on voudrait appliquer 2. Mais ça n'a pas vocation à être une règle absolue, et typiquement dans le cas d'un logiciel libre, les devs n'ont pas de compte à rendre aux utilisateurs, et encore moins à ceux qui ne lisent pas la doc, ou ceux qui n'ont pas le temps d'assurer un peu de maintenance lors des changements de version des dépendances.
En fait, il y a quand même une asymétrie ici, puisque la dette technique est payée par les développeurs du logiciel, alors que la maintenance est payée par les utilisateurs. Appliquer le deuxième point c'est du "transfert de dette", c'est parfois raisonnable mais il y a plein de raisons de penser que ça n'est pas toujours une bonne idée.
2) Cette loi est utilisée comme raison pour limiter les changements dans l'implémentation des API.
Je vois plutôt ça comme un facteur à prendre en compte consciemment. Je suis d'accord que l'utiliser comme excuse à tort et à travers n'est pas une bonne idée.
l'équipe de développement est au service des utilisateurs (c'est douteux), elle part aussi du principe que les devs ont une forme de responsabilité vis-à-vis de la manière dont les utilisateurs exploitent les fonctionnalités des logiciels (là aussi, c'est douteux).
J'ai du mal à comprendre en quoi c'est douteux. Il y a toujours des contraintes supplémentaires mais fondamentalement, si tu n'écris le logiciel pour les utilisateurs de manière à ce qu'il puisse être utilisé d'une manière raisonnable, je comprend pas trop pourquoi (pour qui ?) tu l'écris.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Je suis d'accord que l'utiliser comme excuse à tort et à travers n'est pas une bonne idée.
Là, on ne parle pas d'une raison évoquée pour refuser un patch (par exemple, un patch qui corrigerait un détail insignifiant ou invisible sur la chaîne de caractères), mais d'une instruction préventive : "ne pas modifier cette fonction". Du coup, ça renverse quand même pas mal la logique.
J'ai du mal à comprendre en quoi c'est douteux.
Quel est ton produit? Le logiciel ou le service? Si c'est le service, alors en effet tu peux vouloir tenir compte des coûts induits chez les utilisateurs par les modifications. Si c'est ton logiciel, alors tu dois fournir le meilleur logiciel possible.
Le contexte, ça n'est pas de casser la compatibilité volontairement, c'est de casser la compatibilité involontairement. On imagine que quelqu'un a peut-être exploité une propriété de l'implémentation et que du coup on ne peut pas trop la modifier. Je ne trouve pas ça vraiment "raisonnable" : on subit un coût direct (ou, au moins, une perte d'opportunité) parce qu'il y aurait peut-être un coût indirect chez des utilisateurs.
si tu n'écris le logiciel pour les utilisateurs de manière à ce qu'il puisse être utilisé d'une manière raisonnable, je comprend pas trop pourquoi (pour qui ?) tu l'écris.
Il y a beaucoup de contextes très différents dans lesquels les logiciels sont développés. Typiquement, pour un logiciel libre développé sur ton temps personnel, tu peux développer pour tes besoins, et partager ton travail par altruisme. En tout cas, pour le LL que je développe, je développe pour mes besoins et je diffuse pour des raisons déontologiques. Du coup, les coûts induits par mes choix sur les utilisateurs potentiels ne rentrent pas dans l'équation. Au pire, je peux devoir perdre du temps à aider des gens à trouver la cause du problème, mais rien ne m'y oblige non plus…
Posté par Krunch (site web personnel) .
Évalué à 5 (+3/-0).
Dernière modification le 27 novembre 2024 à 17:58.
on ne parle pas d'une raison évoquée pour refuser un patch (par exemple, un patch qui corrigerait un détail insignifiant ou invisible sur la chaîne de caractères), mais d'une instruction préventive : "ne pas modifier cette fonction". Du coup, ça renverse quand même pas mal la logique.
Ça me semble être exactement la même logique. Juste qu'on annonce la couleur à l'avance. Je suis pas familier avec la philosophie de développement de ce logiciel en particulier mais j'imagine qu'à un moment il va bien falloir changer quelque chose de toute façon et c'est pas un commentaire qui va arrêter cela. J'imagine que ça freine surtout les changements intempestifs et force à considérer l'intérêt des utilisateurs que ça va casser.
le meilleur logiciel possible
Il reste à définir sur quelles métriques tu te bases pour définir le « meilleur logiciel ». Beaucoup de gens vont décider de juger ça sur le fait que le logiciel serve bien ses utilisateurs existants (i.e. que l'équipe de développement est à leur service). Tu peux s/logiciel/service/g et la logique reste la même. Je ne vois rien de douteux là dedans, même s'il peut y avoir d'autres contraintes qui déprioritisent plus ou moins cette notion de service aux utilisateurs.
les coûts induits par mes choix sur les utilisateurs potentiels ne rentrent pas dans l'équation
Mais du coup, il y a relativement peu d'utilisateurs qui vont utiliser ton truc (« ça change tout le temps »), du coup la loi d'Hyrum est aussi moins pertinente du fait qu'il y a peu d'utilisateurs, du coup tu peux joyeusement continuer de casser la comptabilité et tout le monde s'en fout.
Je pense qu'une autre manière de voir cela c'est qu'en temps que développeur tu dois choisir l'équilibre entre te faciliter la vie, faciliter la vie de tes utilisateurs existants et faciliter la vie de tes futurs utilisateurs. Différents projets et différentes organisations vont faire de choix différents. Tant que le choix est fait de manière intentionnelle, ça ne me choque pas trop.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
C'est amusant de voir que cette loi porte le nom de quelqu'un qui travaille sur la maintenance de logiciels à grande échelle1, dans une entreprise qui a cimetière pour les services qu'elle a tuée.
Plus simplement, les versions majeures et les notifications de futur abandon2 plusieurs versions en avance (parfois plusieurs années) sont utilisées pour ce genre de cas.
"Software Engineer at Google, focusing on problems of large-scale software maintenance" ↩
deprecation en Anglais, j'ai pas le mot en Français, à l'aide. ↩
Posté par Krunch (site web personnel) .
Évalué à 4 (+2/-0).
Dernière modification le 25 novembre 2024 à 21:29.
Disclaimer : j'ai travaillé à Google, y compris sur des projets de réduction de dette technique (y compris avec Hyrum) qui ont mené à casser des trucs pas maintenus mais rien qui ai conduit à l'arrêt d'un service disponible publiquement (que je sache).
C'est amusant de voir que cette loi porte le nom de quelqu'un qui travaille sur la maintenance de logiciels à grande échelle1, dans une entreprise qui a cimetière pour les services qu'elle a tuée.
C'est précisément parce que le travail de maintenance / gestion de dette technique est effectué de manière proactive que des projets sont abandonnés. Sinon on laisse tout pourrir, les vieux trucs continuent de fonctionner mais on fini par ne plus pouvoir rien lancer de neuf de manière efficace.
Dans le cas de Google, il y a plusieurs facteurs et je ne suis pas au courant de tout. Mais de mon expérience, historiquement il y a plein de projets qui ont été lancés, qui s'appuient sur l'infrastructure existante, sans vraiment planifier un budget de maintenance pour le projet lui même sur le long terme. Au fil du temps, l'infrastructure évolue (il y a un budget pour ça) et fini par se retrouver dans une situation où l'API doit changer mais où personne ne veut payer le coût de la mise à jour du côté client/projet.
Plus simplement, les versions majeures et les notifications de futur abandon2 plusieurs versions en avance (parfois plusieurs années) sont utilisées pour ce genre de cas.
Pour les API documentés, bien sûr. Mais il y a plein de trucs pour lesquels c'est pas si simple. C'est précisément le sujet de la loi d'Hyrum.
Par ailleurs, aux dernière nouvelles, Hyrum ne travaille plus à Google.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
C'est précisément parce que le travail de maintenance / gestion de dette technique est effectué de manière proactive que des projets sont abandonnés. Sinon on laisse tout pourrir, les vieux trucs continuent de fonctionner mais on fini par ne plus pouvoir rien lancer de neuf de manière efficace.
Il me semble que l'ironie c'est de dire qu'abandonner le projet est infiniment plus coûteux pour tes utilisateurs que le fait de faire évoluer ton API. Si tu refuse de faire évoluer ton API en prenant pour argument que les utilisateurs ne peuvent pas en payer le coût abandonner le projet est bien pire pour tes utilisateurs.
Posté par Krunch (site web personnel) .
Évalué à 3 (+1/-0).
Dernière modification le 27 novembre 2024 à 12:39.
Les utilisateurs d'un service d'infrastructure de base (I), ce sont des services de plus haut niveau (S1, S2,…). Les utilisateurs de ces services sont potentiellement les utilisateurs finaux U1 pour S2, U2 pour S2,….
Dans la situation que je décris, il y a de l'argent pour faire évoluer I et S1 mais pas S2. Pour une raison ou l'autre, pour pouvoir faire évoluer S1, il faut faire évoluer I (e.g. limites de mise à l'échelle). Les utilisateurs U2 ne sont organisationnellement pas vraiment en mesure de payer pour S2 (e.g. c'est un service « gratuit ») et son évolution.
Mais oui, au final c'est une décision du management de prioritiser un certains groupe d'utilisateurs (e.g. U1 et leur service S1 qui grandit à 3000% par an) au détriment d'un autre (e.g. U2 et leur service S2 qu'on n'a pas réussi à monétiser suffisamment). On peut aussi voir ça comme prioritiser les nouveaux services (« potentiel prometteurs ») sur les anciens (« on a essayé, c'est pas rentable »). Le management pourrait choisir ses priorités autrement mais à Google j'ai l'impression que c'était (c'est ?) souvent comme ça.
Je ne pense pas que qui que ce soit ai donné comme argument que c'était pour le bien des utilisateurs U2 de casser S2 (bon, parfois il y a un service équivalent S3 et ça peut être une manière de forcer la migration vers ce truc qui est censé être mieux pour eux). Les utilisateurs ne sont pas un groupe uniforme, surtout quand on considère tous les services/logiciels dépendants.
Dans ce contexte, la loi d'Hyrum est un juste un facteur à prendre en compte quand on prend la décision de ce qu'il est important de prioritiser.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Google tue n'importe quel service sans distinction du niveau que tu décris. Nexus player, Nexus Q, Chromebook Pixel, Fabric, Tez, Chrome Apps, Freebase,… ne sont pas à destination d'utilisateurs finaux, mais sont à destination de professionnels et pour une partie d'entre eux étaient payant.
On peut aussi voir ça comme prioritiser les nouveaux services (« potentiel prometteurs ») sur les anciens (« on a essayé, c'est pas rentable »). Le management pourrait choisir ses priorités autrement mais à Google j'ai l'impression que c'était (c'est ?) souvent comme ça.
Je l'avais vu décrit autrement d'une part Google encourage la création de nouveau projet et ne sait pas encourager leur maintenance d'autre part tous les projets souffrent de la comparaison avec les projets qui génèrent de la publicité donc si ça ne produit pas de la donnée ou des displays de pub ça disparaîtra à terme.
Dans ce contexte, la loi d'Hyrum est un juste un facteur à prendre en compte quand on prend la décision de ce qu'il est important de prioritiser.
Je dirais qu'elle est peut être prise en compte par les ingé et globalement ignorée par le management (là où ça pose le plus de problème).
Je trouve que tenter de créer des méta-lois pour se torcher avec les 15 années suivantes est à minima risible.
Je l'avais vu décrit autrement d'une part Google encourage la création de nouveau projet et ne sait pas encourager leur maintenance
At Google, product launches the only way to get promoted "You launch a service or a major overhaul and you put in your promo package. No one ever [obscenity] get [sic] promoted for 'maintaining' or 'fixing something broken'. No, it is all about launching and then putting the launch in your promo package."
C'est un peu exagéré mais c'est l'esprit, oui. Il était (est ?) beaucoup plus facile de démontrer un « impact » (et donc d'être promu) en lançant un nouveau service qu'en faisant de la maintenance.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
ne sont pas à destination d'utilisateurs finaux, mais sont à destination de professionnels
Par « utilisateurs finaux » je veux dire « utilisateurs externes ». Professionnels ou pas, ça n'a pas d'importance. Qu'ils paient ou pas non plus dans une certaine mesure. Mon exemple de service « gratuit » était juste un exemple.
Je l'avais vu décrit autrement
Je pense qu'on dit la même chose.
Je trouve que tenter de créer des méta-lois pour se torcher avec les 15 années suivantes est à minima risible.
Cette « loi » est juste une observation (d'un ingénieur) dont on peut faire ce qu'on veut. Elle me semble correcte. Je suis d'accord qu'on peut rire du management qui n'en fait pas bon usage :)
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Je pense que la formulation d'Hyrum est plus facile à comprendre pour le développeur moyen dans un contexte moderne. Ça vaut peut-être la peine de faire le lien dans l'article Wikipedia correspondant.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# et xkcd associé
Posté par woffer 🐧 . Évalué à 4 (+3/-0).
https://xkcd.com/1172/
# Merci pour grep.app
Posté par shbrol . Évalué à 2 (+1/-0).
Merci pour grep.app, je ne connaissais pas, c'est joli.
# Dette technique...
Posté par arnaudus . Évalué à 7 (+5/-1).
Ça n'est pas quand même un appel à accumuler de la dette technique? Les bugs d'interface, ça existe, et ça impose que tout le monde dans les dizaines d'années qui vont suivre vont devoir se taper le même bug, la même lecture de la doc, la même procédure d'essais et erreurs, pour finalement se rendre compte qu'en effet il y a un bug d'interface. Tout ça c'est aussi du temps perdu pour plein d'utilisateurs, et il n'est pas du tout garanti qu'à force, ce temps ne soit pas supérieur au temps nécessaire pour corriger le problème dans les logiciels qui "exploitent" le bug au moment du changement de version.
Par exemple, dans l'exemple cité, il me semble assez évident que l'erreur est de ne pas afficher l'identifiant de l'erreur ("MaxBytesError") mais seulement sa description en anglais ("http: request body too large"). Comment tu fais pour l'internationalisation? Comment tu fais si tu t'aperçois que le texte ne couvre pas tous les cas (par exemple "request body too large or insufficient memory"?). Laisser ça intouchable, c'est admettre que ce bout de code ne peut pas être amélioré.
[^] # Re: Dette technique...
Posté par Krunch (site web personnel) . Évalué à 4 (+2/-0).
Si tu lis la page canonique sur le sujet ainsi que le chapitre associé dans le SWE Book, tu peux voir que l'idée c'est pas d'appeler à accumuler de la dette technique de manière indiscriminée mais que, si tu as beaucoup d'utilisateurs, payer ta dette technique peut rapidement coûter cher.
Voire aussi
https://higherorderlogic.com/programming/2023/10/06/bad-code-isnt-technical-debt-its-an-unhedged-call-option.html
https://apenwarr.ca/log/?m=202306
Et tant qu'on y est https://technology.riotgames.com/news/taxonomy-tech-debt
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Dette technique...
Posté par arnaudus . Évalué à 5 (+3/-1).
En fait, j'ai quand même l'impression qu'il y deux niveaux dans cette discussion:
1) La loi d'Hyrum dit que les utilisateurs vont être amenés à utiliser plus ou moins consciemment les propriétés concrètes de l'implémentation des API qui ne font pas partie de leur abstraction.
2) Cette loi est utilisée comme raison pour limiter les changements dans l'implémentation des API.
Le deuxième point n'est pas une constatation, c'est une décision de développement qu'on peut trouver discutable. Elle part du principe que l'équipe de développement est au service des utilisateurs (c'est douteux), elle part aussi du principe que les devs ont une forme de responsabilité vis-à-vis de la manière dont les utilisateurs exploitent les fonctionnalités des logiciels (là aussi, c'est douteux). Bien sûr, c'est pragmatique, et il y a plein de raisons pour lesquelles on voudrait appliquer 2. Mais ça n'a pas vocation à être une règle absolue, et typiquement dans le cas d'un logiciel libre, les devs n'ont pas de compte à rendre aux utilisateurs, et encore moins à ceux qui ne lisent pas la doc, ou ceux qui n'ont pas le temps d'assurer un peu de maintenance lors des changements de version des dépendances.
En fait, il y a quand même une asymétrie ici, puisque la dette technique est payée par les développeurs du logiciel, alors que la maintenance est payée par les utilisateurs. Appliquer le deuxième point c'est du "transfert de dette", c'est parfois raisonnable mais il y a plein de raisons de penser que ça n'est pas toujours une bonne idée.
[^] # Re: Dette technique...
Posté par Krunch (site web personnel) . Évalué à 3 (+1/-0).
Je vois plutôt ça comme un facteur à prendre en compte consciemment. Je suis d'accord que l'utiliser comme excuse à tort et à travers n'est pas une bonne idée.
J'ai du mal à comprendre en quoi c'est douteux. Il y a toujours des contraintes supplémentaires mais fondamentalement, si tu n'écris le logiciel pour les utilisateurs de manière à ce qu'il puisse être utilisé d'une manière raisonnable, je comprend pas trop pourquoi (pour qui ?) tu l'écris.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Dette technique...
Posté par arnaudus . Évalué à 2 (+0/-1).
Là, on ne parle pas d'une raison évoquée pour refuser un patch (par exemple, un patch qui corrigerait un détail insignifiant ou invisible sur la chaîne de caractères), mais d'une instruction préventive : "ne pas modifier cette fonction". Du coup, ça renverse quand même pas mal la logique.
Quel est ton produit? Le logiciel ou le service? Si c'est le service, alors en effet tu peux vouloir tenir compte des coûts induits chez les utilisateurs par les modifications. Si c'est ton logiciel, alors tu dois fournir le meilleur logiciel possible.
Le contexte, ça n'est pas de casser la compatibilité volontairement, c'est de casser la compatibilité involontairement. On imagine que quelqu'un a peut-être exploité une propriété de l'implémentation et que du coup on ne peut pas trop la modifier. Je ne trouve pas ça vraiment "raisonnable" : on subit un coût direct (ou, au moins, une perte d'opportunité) parce qu'il y aurait peut-être un coût indirect chez des utilisateurs.
Il y a beaucoup de contextes très différents dans lesquels les logiciels sont développés. Typiquement, pour un logiciel libre développé sur ton temps personnel, tu peux développer pour tes besoins, et partager ton travail par altruisme. En tout cas, pour le LL que je développe, je développe pour mes besoins et je diffuse pour des raisons déontologiques. Du coup, les coûts induits par mes choix sur les utilisateurs potentiels ne rentrent pas dans l'équation. Au pire, je peux devoir perdre du temps à aider des gens à trouver la cause du problème, mais rien ne m'y oblige non plus…
[^] # Re: Dette technique...
Posté par Krunch (site web personnel) . Évalué à 5 (+3/-0). Dernière modification le 27 novembre 2024 à 17:58.
Ça me semble être exactement la même logique. Juste qu'on annonce la couleur à l'avance. Je suis pas familier avec la philosophie de développement de ce logiciel en particulier mais j'imagine qu'à un moment il va bien falloir changer quelque chose de toute façon et c'est pas un commentaire qui va arrêter cela. J'imagine que ça freine surtout les changements intempestifs et force à considérer l'intérêt des utilisateurs que ça va casser.
Il reste à définir sur quelles métriques tu te bases pour définir le « meilleur logiciel ». Beaucoup de gens vont décider de juger ça sur le fait que le logiciel serve bien ses utilisateurs existants (i.e. que l'équipe de développement est à leur service). Tu peux s/logiciel/service/g et la logique reste la même. Je ne vois rien de douteux là dedans, même s'il peut y avoir d'autres contraintes qui déprioritisent plus ou moins cette notion de service aux utilisateurs.
Mais du coup, il y a relativement peu d'utilisateurs qui vont utiliser ton truc (« ça change tout le temps »), du coup la loi d'Hyrum est aussi moins pertinente du fait qu'il y a peu d'utilisateurs, du coup tu peux joyeusement continuer de casser la comptabilité et tout le monde s'en fout.
Je pense qu'une autre manière de voir cela c'est qu'en temps que développeur tu dois choisir l'équilibre entre te faciliter la vie, faciliter la vie de tes utilisateurs existants et faciliter la vie de tes futurs utilisateurs. Différents projets et différentes organisations vont faire de choix différents. Tant que le choix est fait de manière intentionnelle, ça ne me choque pas trop.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# Ironie
Posté par cg . Évalué à 5 (+3/-0).
C'est amusant de voir que cette loi porte le nom de quelqu'un qui travaille sur la maintenance de logiciels à grande échelle1, dans une entreprise qui a cimetière pour les services qu'elle a tuée.
Plus simplement, les versions majeures et les notifications de futur abandon2 plusieurs versions en avance (parfois plusieurs années) sont utilisées pour ce genre de cas.
"Software Engineer at Google, focusing on problems of large-scale software maintenance" ↩
deprecation en Anglais, j'ai pas le mot en Français, à l'aide. ↩
[^] # Re: Ironie
Posté par woffer 🐧 . Évalué à 4 (+3/-0).
Obsolète ? Obsolescence ?
[^] # Re: Ironie
Posté par guitou . Évalué à 2 (+1/-0).
Hello.
Dépréciation, tout bêtement.
(Pour une fois j'ai pris la peine de mettre les accents dans ma prose!)
++
Gi)
[^] # Re: Ironie
Posté par cg . Évalué à 3 (+1/-0).
Merci ! J'avais cherché, et justement il m'a semblé que dépréciation est un faux-ami, car il a surtout un sens économico-financier en langue français.
En cherchant de nouveau, je trouve :
Et donc obsolète et déprécié.
[^] # Re: Ironie
Posté par Krunch (site web personnel) . Évalué à 4 (+2/-0). Dernière modification le 25 novembre 2024 à 21:29.
Disclaimer : j'ai travaillé à Google, y compris sur des projets de réduction de dette technique (y compris avec Hyrum) qui ont mené à casser des trucs pas maintenus mais rien qui ai conduit à l'arrêt d'un service disponible publiquement (que je sache).
C'est précisément parce que le travail de maintenance / gestion de dette technique est effectué de manière proactive que des projets sont abandonnés. Sinon on laisse tout pourrir, les vieux trucs continuent de fonctionner mais on fini par ne plus pouvoir rien lancer de neuf de manière efficace.
Dans le cas de Google, il y a plusieurs facteurs et je ne suis pas au courant de tout. Mais de mon expérience, historiquement il y a plein de projets qui ont été lancés, qui s'appuient sur l'infrastructure existante, sans vraiment planifier un budget de maintenance pour le projet lui même sur le long terme. Au fil du temps, l'infrastructure évolue (il y a un budget pour ça) et fini par se retrouver dans une situation où l'API doit changer mais où personne ne veut payer le coût de la mise à jour du côté client/projet.
Pour les API documentés, bien sûr. Mais il y a plein de trucs pour lesquels c'est pas si simple. C'est précisément le sujet de la loi d'Hyrum.
Par ailleurs, aux dernière nouvelles, Hyrum ne travaille plus à Google.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Ironie
Posté par barmic 🦦 . Évalué à 2 (+0/-0).
Il me semble que l'ironie c'est de dire qu'abandonner le projet est infiniment plus coûteux pour tes utilisateurs que le fait de faire évoluer ton API. Si tu refuse de faire évoluer ton API en prenant pour argument que les utilisateurs ne peuvent pas en payer le coût abandonner le projet est bien pire pour tes utilisateurs.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Ironie
Posté par Krunch (site web personnel) . Évalué à 3 (+1/-0). Dernière modification le 27 novembre 2024 à 12:39.
Les utilisateurs d'un service d'infrastructure de base (I), ce sont des services de plus haut niveau (S1, S2,…). Les utilisateurs de ces services sont potentiellement les utilisateurs finaux U1 pour S2, U2 pour S2,….
Dans la situation que je décris, il y a de l'argent pour faire évoluer I et S1 mais pas S2. Pour une raison ou l'autre, pour pouvoir faire évoluer S1, il faut faire évoluer I (e.g. limites de mise à l'échelle). Les utilisateurs U2 ne sont organisationnellement pas vraiment en mesure de payer pour S2 (e.g. c'est un service « gratuit ») et son évolution.
Mais oui, au final c'est une décision du management de prioritiser un certains groupe d'utilisateurs (e.g. U1 et leur service S1 qui grandit à 3000% par an) au détriment d'un autre (e.g. U2 et leur service S2 qu'on n'a pas réussi à monétiser suffisamment). On peut aussi voir ça comme prioritiser les nouveaux services (« potentiel prometteurs ») sur les anciens (« on a essayé, c'est pas rentable »). Le management pourrait choisir ses priorités autrement mais à Google j'ai l'impression que c'était (c'est ?) souvent comme ça.
Je ne pense pas que qui que ce soit ai donné comme argument que c'était pour le bien des utilisateurs U2 de casser S2 (bon, parfois il y a un service équivalent S3 et ça peut être une manière de forcer la migration vers ce truc qui est censé être mieux pour eux). Les utilisateurs ne sont pas un groupe uniforme, surtout quand on considère tous les services/logiciels dépendants.
Dans ce contexte, la loi d'Hyrum est un juste un facteur à prendre en compte quand on prend la décision de ce qu'il est important de prioritiser.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Ironie
Posté par barmic 🦦 . Évalué à 2 (+0/-0).
Google tue n'importe quel service sans distinction du niveau que tu décris. Nexus player, Nexus Q, Chromebook Pixel, Fabric, Tez, Chrome Apps, Freebase,… ne sont pas à destination d'utilisateurs finaux, mais sont à destination de professionnels et pour une partie d'entre eux étaient payant.
Je l'avais vu décrit autrement d'une part Google encourage la création de nouveau projet et ne sait pas encourager leur maintenance d'autre part tous les projets souffrent de la comparaison avec les projets qui génèrent de la publicité donc si ça ne produit pas de la donnée ou des displays de pub ça disparaîtra à terme.
Je dirais qu'elle est peut être prise en compte par les ingé et globalement ignorée par le management (là où ça pose le plus de problème).
Je trouve que tenter de créer des méta-lois pour se torcher avec les 15 années suivantes est à minima risible.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Ironie
Posté par Faya . Évalué à 4 (+2/-0).
At Google, product launches the only way to get promoted
"You launch a service or a major overhaul and you put in your promo package. No one ever [obscenity] get [sic] promoted for 'maintaining' or 'fixing something broken'. No, it is all about launching and then putting the launch in your promo package."
[^] # Re: Ironie
Posté par Krunch (site web personnel) . Évalué à 3 (+1/-0).
C'est un peu exagéré mais c'est l'esprit, oui. Il était (est ?) beaucoup plus facile de démontrer un « impact » (et donc d'être promu) en lançant un nouveau service qu'en faisant de la maintenance.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Ironie
Posté par Krunch (site web personnel) . Évalué à 3 (+1/-0).
Par « utilisateurs finaux » je veux dire « utilisateurs externes ». Professionnels ou pas, ça n'a pas d'importance. Qu'ils paient ou pas non plus dans une certaine mesure. Mon exemple de service « gratuit » était juste un exemple.
Je pense qu'on dit la même chose.
Cette « loi » est juste une observation (d'un ingénieur) dont on peut faire ce qu'on veut. Elle me semble correcte. Je suis d'accord qu'on peut rire du management qui n'en fait pas bon usage :)
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Ironie
Posté par barmic 🦦 . Évalué à 3 (+1/-0).
De mon point de c'est une autre façon de parler du behavioral subtyping tel que Barbara Liskov en parlait il y a 30 ans.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Ironie
Posté par Krunch (site web personnel) . Évalué à 3 (+1/-0).
TIL
Je pense que la formulation d'Hyrum est plus facile à comprendre pour le développeur moyen dans un contexte moderne. Ça vaut peut-être la peine de faire le lien dans l'article Wikipedia correspondant.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.