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...
[^] # Re: Dette technique...
Posté par arnaudus . En réponse au lien Hyrum's Law (ou ne pas changer une API même cassée). Évalué à 2.
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...