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 Krunch (courriel, site web personnel) . En réponse au lien Hyrum's Law (ou ne pas changer une API même cassée). Évalué à 3. 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.