Question:
Éthique de la "technique du canard"
Josh Johnson
2018-03-10 05:56:47 UTC
view on stackexchange narkive permalink

En programmation, la Technique Duck est une technique par laquelle vous placez un oubli évident et facile dans votre code dans l'espoir qu'il attirera l'attention lors de la révision et atténuera les changements de conception importants et chronophages.

Il y avait cette équipe dans mon entreprise bien connue pour être très pointilleuse au moment de la révision; Si nous utilisions Lib A, ils voudraient la Lib B. Mais si nous avions utilisé Lib B, ils voudraient Lib A. Ils ne sont pas satisfaits de ce modèle de conception et veulent en voir un autre. Mais je jure que si nous avions utilisé à l'origine le modèle, ils ont suggéré qu'ils auraient voulu l'autre. C'était comme s'ils devaient ajouter quelques commentaires pour démontrer leur valeur. Ces grands changements étaient problématiques car ils pouvaient transformer une tâche d'une heure en plusieurs heures, s'éternisant au fil des jours, bloquant la progression. Et je sais ce que vous pensez: pourquoi ne pas discuter du changement avec cette équipe au préalable? Nous faisions. Nous avions des réunions pour présenter le changement, expliquer comment la conception maintient la compatibilité ascendante et nous assurer qu'ils se sentaient entendus, avaient des commentaires et étaient à bord. Cela n'avait pas d'importance. Une fois que la révision du code est arrivée, c'était comme si tout ce qui était convenu avait été oublié.

À un moment donné, un collègue et moi avons dû modifier une bibliothèque que nous utilisions et qu'ils possédaient afin que nous puissions utiliser le modification de notre programme. C'était un petit changement, mais nous avons soupiré, nous nous sommes accroupis et nous y sommes arrivés, nous préparant à la révision du code. Nous étions en train de programmer le changement en binôme et de lui donner un bref aperçu avant de le soumettre à la révision du code. Connaissant la tendance à la perspicacité de cette autre équipe, j'avais une idée:

Coéquipier: Devrions-nous remplacer cela ici par la syntaxe abrégée de la dernière version du langage introduite?

Moi: Bonne idée ... en fait, laissez-la pour le moment.

Il y a eu quelques autres cas. Rien de critique comme laisser un bogue mais des choses comme laisser la syntaxe que nous savions que l'autre équipe n'aimait pas, laissant de la place pour les méthodes à extraire ou les variables à renommer. Cela a fonctionné à merveille. Ils ont commenté chaque canard, nous avons répondu "Merci! Réparer maintenant!" et c'était ça. La révision du code s'est terminée en 10 minutes environ et nous avons pu continuer sans être bloqués.

Mais cela m'a fait réfléchir, y a-t-il des problèmes d'éthique à ce sujet? Je n'aime pas particulièrement le faire et je ne le fais pour aucune autre équipe. Mais dans ce cas, nous avons pu transformer une révision de code potentielle de 2 heures dans les deux sens en 10 minutes. Une victoire dans mon livre. Je suis curieux de savoir ce que les autres pensent ou s'ils ont des solutions alternatives pour faire face à des équipes difficiles.

Modifier pour plus de clarté: cette question ne cesse de se poser, donc je voulais y répondre ici.

Si l'équipe perd le temps de tout le monde, pourquoi ne pas les affronter, les repousser ou parler à la direction?

Nous avons d'abord suivi tous les canaux habituels / officiels . Ils n'ont pas eu le dernier mot sur la révision du code (bien que ne pas obtenir leur adhésion aurait été une perte politique pour moi) et tout ce qui était carrément stupide ou dangereux, nous ne nous accommoderions pas, mais parfois l'acquiescement à la demande permettrait d'économiser davantage temps sur le long terme. Je changerais volontiers de petits trucs comme "espaces vs tabulation" ou "placement d'accolades". Des choses plus importantes sur lesquelles je repousserais et demanderais une raison pour laquelle il valait la peine de passer du temps à faire le changement. Parfois cela fonctionnait parfois non. Moi-même et d'autres les avaient approchés individuellement soit au travail, soit au déjeuner ou autour de bières en disant que ces changements de conception de code étaient préjudiciables au progrès et difficiles à travailler. J'ai signalé leur comportement comme problématique à la direction et d'autres peuvent l'être également.

Dans l'idéal, on leur dirait que leur comportement est inacceptable, on verrait leurs erreurs et on changerait. Mais les humains ne sont pas des ordinateurs et n'ont pas vraiment à faire quoi que ce soit de la manière que moi-même ou n'importe qui d'autre voudrait voir faire, indépendamment du temps et de l'argent gaspillés par l'entreprise. Toute critique pourrait être contrée par "Nous ne perdons pas de temps, nous nous assurons que le code est fait de la bonne façon. Cela vaut certainement un peu plus de temps à l'avance, n'est-ce pas?" Ce n'est malheureusement pas vraiment noir et blanc et à la fin, comme je l'ai mentionné quelque part ci-dessous, j'ai décidé que ce n'était pas une colline sur laquelle je voulais mourir. Surtout parce que mes interactions directes avec cette équipe étaient peu fréquentes.

Il est difficile d'expliquer en plus de le décrire comme "difficile pour des raisons de pointillosité". Par exemple, nous avons essayé d'automatiser les éléments stylistiques puisque c'est une tâche de l'éditeur, mais ils proposeraient des règles alambiquées que l'éditeur ne pouvait tout simplement pas gérer de manière cohérente. Je ne pense pas qu'ils étaient malveillants. Des trucs comme, peut-être qu'une semaine ils aimeraient vraiment le Pattern A. Sachant cela, je m'assurerais d'utiliser le Pattern A sur leur code le cas échéant. Mais à un moment donné, ils ont lu quelque part que le modèle A est mauvais et que tout le monde devrait utiliser le modèle B. viendrait au moment de l'examen. Ils avaient un petit fief étrange et ils le dirigeaient d'une main de fer, mais ils étaient dans l'entreprise depuis longtemps et la direction les aimait. Ils formaient finalement un joli groupe de personnes, juste un peu bizarre. C'est juste une de ces choses étranges sur le lieu de travail qui semblent probablement folles à moins que vous n'ayez rencontré quelque chose de similaire.

Peut-être pas entièrement lié à votre question principale, mais pourquoi n'aggraveriez-vous pas le comportement de cette équipe?S'il s'agit d'un problème courant et que vous pouvez indiquer des chiffres réels en ce qui concerne les retards qu'ils ajoutent, vous * pourriez * être en mesure de poursuivre une option plus constructive au lieu de les contourner.
Oh nous avons repoussé.Mais selon la phase de la lune, ils concéderaient à contrecœur ou se battraient bec et ongles.Les confronter au sujet de leur comportement a conduit à une attitude défensive et le signalement de leur comportement a conduit à des relations tendues sans changement de comportement.En fin de compte, c'était l'une des batailles que j'ai décidé de ne pas choisir
Quelles sont les conséquences du non-respect de leurs recommandations?Sont-ils tenus de signer?
@colmde J'ai édité ma question avec plus de détails, mais ils n'avaient pas techniquement à se déconnecter et parfois je repoussais et disais, "nous allons aller de l'avant avec cette solution pour être débloqué, mais nous pouvons la revoir à l'avenir si vousJ'aurais aimé "mais en raison de leur mandat dans l'entreprise, en faire trop ou simplement les ignorer m'aurait gagné des ennemis.Comme Joe Stevens l'a dit ci-dessus, il s'agissait parfois de laisser aller "faire la bonne chose" (rapporter chaque exemple du comportement) et simplement essayer de maintenir la paix.
@JoshJohnson Que pensez-vous que leur réaction serait à cela si vous expliquiez ce que vous avez fait et pourquoi?Certaines équipes ce serait un haussement d'épaules et "je comprends", d'autres ce serait une déclaration de guerre.
Si vous obtenez une pré-approbation sur des éléments tels que les bibliothèques, créez un document sur la portée du projet qui les définit.Toutes les parties concernées approuveraient le document et si le problème se posait plus tard lors de l'examen, vous pourriez simplement faire référence au document.Changer une bibliothèque pourrait être un changement massif.
@Myles C'était une chose ponctuelle et pas une pratique courante, ce qui peut changer quelque peu les choses (ou pas).Imaginer que quelqu'un me fasse ça puis m'en parle, j'aurais bien ri que mes préférences étaient si prévisibles, puis je réévaluerais mes valeurs autour de la CR, bien que plus jeune, je me sois indigné.Pour eux, j'imagine qu'ils se seraient sentis lésés et que ce serait plus proche d'une déclaration de guerre.Mais je pourrais aussi imaginer en rire en buvant un verre avec eux toutes ces années plus tard.Dur à dire.Bonne perspicacité, merci
Cinq réponses:
#1
+15
Bernhard Barker
2018-03-10 18:48:25 UTC
view on stackexchange narkive permalink

Ne faites pas cela.

Si quelqu'un suggère un changement (qui prend du temps) (ou plusieurs petits changements) à quelque chose d'équivalent ou pire sans aucune justification, vous devriez repousser probablement cela au lieu de simplement faire le changement. L'examen n'est pas (ou du moins ne devrait pas être) un processus à sens unique dans lequel vous devez simplement faire tout ce que le critique dit sans poser de questions, même si vous avez un bon argument pour ne pas le faire. Et, qui sait, peut-être qu'ils ont un meilleur argument que vous ne le pensez et discuter du changement vous amène à apprendre quelque chose à l'un ou l'autre ou aux deux.

Si vous ne voulez pas simplement être en désaccord avec eux (ou 't work), vous pouvez toujours essayer l'approche "merci, mais non merci":

[D'accord avec eux] Vous avez peut-être un bon point. [Signalez le problème] Bien qu'il semble que cela puisse prendre du temps, nous préférons garder les choses telles qu'elles sont pour le moment, [Donnez les raisons pour lesquelles ils peuvent ne discute pas avec] car ce que nous avons déjà terminé fonctionne et cela nous permet de nous concentrer sur des problèmes plus urgents. [Fin sur une note positive] Nous allons certainement en prendre note et le garder à l'esprit à l'avenir!

Bien sûr, cela ne mènerait pas nécessairement à leur donner leur approbation.

S'il ne s'agit que de modifications mineures , le fait de repousser ne vaut peut-être pas la peine ni le temps ni les efforts nécessaires et vous devriez probablement simplement apporter les modifications (à moins que vous n'obteniez tout un tas de ceux-ci à chaque examen, et le temps nécessaire pour les résoudre s’additionne rapidement).

Si quelqu'un semble obligé de donner au moins un commentaire (même inutile ou nuisible) pour chaque changement, vous devriez d'abord en discuter avec lui, puis avec la direction, car ils devraient arrêter de le faire. J'ai envie de donner de la visibilité à ce que vous faites (car une simple critique «tout bon» ne dit à personne si vous avez passé quelques secondes ou quelques heures dessus), mais vous faites cela en remarquant régulièrement des notes subtiles mais des problèmes importants, pas en faisant perdre du temps à tout le monde avec des commentaires inutiles.

Le mal de la "technique du canard" est que vous perdez maintenant le temps des autres, ce qui pourrait ont une variété de conséquences, comme le fait de manquer d'autres problèmes plus importants dans votre code, de s'éloigner de leur travail ou de se faire découvrir et d'être réprimandé.

Si vous avez déjà tout essayé de ce qui précède ad nauseam , vous êtes probablement à court d'options et vous voudrez peut-être faire tout ce qui fonctionne pour votre processus de révision irréversible.

C'est la bonne réponse.Aussi simple et inoffensive que puisse paraître cette "technique de canard", elle est finalement mauvaise car, à tout le moins, elle laisse le plus gros problème de * "cette autre équipe perd le temps de tout le monde avec des commentaires inutiles" * sans réponse.** N'utilisez pas de solution de hack;résoudre la cause profonde. **
Cela peut sembler le cas, mais à en juger par les commentaires de suivi du PO, le fait de repousser ou de faire rapport à la direction ne semble pas utile, alors faire la bonne chose peut causer plus de tort et de perte de temps que de bien.
C'est correct.Le fait de repousser était généralement un jeu à somme nulle avec cette équipe et ils avaient été interrogés et signalés à la direction.La suggestion de «parler à la direction et de la faire changer ou d'être renvoyée» revient sans cesse, j'ai donc modifié ma question initiale pour y répondre plus en détail.J'espère que cela aide!
AilinepvrfCMT édité.
Merci @Dukeling!«[Donnez les raisons avec lesquelles ils ne peuvent pas discuter]» est le nœud du problème;Je pourrais trouver des raisons infinies pour lesquelles le code doit être changé si je le voulais.Et je dois noter que c'était une chose ponctuelle.Cela ressemblait à un pouvoir bien trop grand et trop terrible à exercer.Après avoir quitté cette entreprise, je n'ai rencontré personne comme eux.Mais votre réponse m'a donné une nouvelle perspective sur les pièges de cette "technique".
Un autre risque avec la "technique du canard" est qu'elle ajoute intentionnellement des erreurs / mauvais code, * dans le but d'ajouter des erreurs / mauvais code *.Que se passe-t-il si l'équipe d'examen manque le canard d'une manière ou d'une autre?Et si vous oubliez de retirer le canard une fois qu'il a manqué?Maintenant, vous avez des bogues dans votre code qui ne devraient même pas être là pour commencer.
#2
+10
A. I. Breveleri
2018-03-10 06:33:42 UTC
view on stackexchange narkive permalink

Le seul problème n’est pas éthique mais pratique: si l’autre équipe EST en mesure de contribuer quelque chose d’utile, vous réduisez la probabilité d’en entendre parler. Sinon, vous semblez totalement justifié d'utiliser n'importe quelle méthode pour maintenir le processus de révision du code sur la bonne voie.

Cette équipe a-t-elle une histoire établie de fournir une contribution précieuse avec ses objections légendaires? Je pense que le fait est que, même s'ils peuvent le faire, toute contribution utile de leur part ne vaut pas la peine de parcourir des tas de brun collant pour y arriver.

Une fois que la révision du code est arrivée, c'était comme si tout ce qui était convenu avait été oublié.

Cela me fait penser qu'ils ont amplement l'occasion d'injecter n'importe quel de véritables préoccupations dans le processus de conception, bien loin de la révision du code. Cela signifie également que c'est leur comportement qui vous a poussé à manipuler le processus de révision du code.

Je ne vois aucune raison éthique de censurer votre utilisation de la technique du canard dans ce cas. Au contraire, je vous félicite pour la pertinence de votre solution.

#3
+4
gnasher729
2018-03-10 15:49:54 UTC
view on stackexchange narkive permalink

Il semble que la manière dont votre entreprise procède aux révisions de code, et en particulier la façon dont un autre groupe effectue les révisions, est une perte de temps totalement ridicule. C'est ridicule, pas ridicule, parce que c'est tellement ridicule qu'il ne vaut même pas la peine de l'épeler correctement.

Si j'étais le responsable des deux groupes, je serais très, très en colère si je découvrais ce qui se passe. Il n'y a rien de mal dans ce que vous avez fait, mais vous ne devriez pas avoir à le faire. Je parlerais à votre responsable, je lui dirais que quoi que vous fassiez, ils vont vouloir exactement le contraire, et que cela crée un travail totalement inutile. Signalez le subterfuge que vous avez utilisé - qui fait également perdre du temps, un peu moins. Votre entreprise paie tous les travaux inutiles. Vous pourriez faire des choses utiles pendant cette période. Et l'autre groupe va découvrir ce que vous faites et cela aggravera les choses.

Votre responsable doit le savoir, et votre responsable doit agir.

Merci!Et d'accord.Ce processus d'examen est sous-optimal, mais c'est seulement cette équipe qui a insisté sur ce niveau de contrôle d'accès.D'autres équipes ont été plus laxistes et satisfaites de tout, tant qu'elles avaient une visibilité / une contribution au changement, qu'il y avait des tests et qu'il n'y avait pas de bogues évidents ou de problèmes de conception.J'ai informé mon responsable qui a parlé avec son responsable et leur responsable et les choses changeraient temporairement mais finiraient par revenir.
#4
+3
Fattie
2018-03-10 20:28:52 UTC
view on stackexchange narkive permalink

Le travail n'est pas le lycée.

Supposons qu'un de vos collègues suggère fréquemment de petits changements inutiles qui sont des changements pour le plaisir des changements et qui ralentissent les progrès.

Ce que vous dites est:

Hmm. Steve, vous suggérez fréquemment de petits changements inutiles qui sont des changements pour le plaisir des changements et qui ralentissent les progrès.

Pour répéter, le travail n'est pas le lycée .

Bouclez votre ceinture et faites le travail!

Ha tu prêches à la chorale.J'aurais probablement dû ajouter cela dans mon histoire, mais l'équipe avait été rapportée à la direction par moi-même et d'autres et je les avais approchés directement en leur disant quelque chose de similaire à ce que vous proposez (bien que plus gentil).Cela a généralement conduit à une attitude défensive, à une cessation temporaire de la difficulté, puis à une réversion un peu plus tard, mais maintenant avec des relations tendues.Je les aimais vraiment mais ils avaient ... des personnalités étranges.En fin de compte, j'ai décidé que j'avais de plus grandes batailles à combattre et j'étais prêt à radier cette équipe comme quelque chose avec lequel je pourrais faire la paix de manière créative lorsque nos chemins se croisaient.
heh good one @JoshJohnson - totalement compris
«Le travail n'est pas le lycée» Malheureusement, cela peut ressembler beaucoup plus au lycée que nous le souhaiterions.En particulier, les hiérarchies sociales ont un pouvoir réel.Surtout si Steve est plus ancien que vous, lui dire que ses suggestions ne sont pas utiles peut simplement entraîner une dispute et / ou lui expliquer longuement pourquoi vous vous trompez et que ses suggestions sont importantes à suivre.
salut @jhocking - votre exemple concerne quelqu'un ** supérieur ** à vous au travail.ce contrôle qualité concerne les collègues.(En ce qui concerne les * supérieurs *, je suis tout à fait d'accord avec vous. (1) faites exactement ce qu'ils disent à tout moment, sans discussion et avec une attitude positive ou (2) lancez votre propre entreprise. C'est comme ça.: /)
#5
+3
HLGEM
2018-03-12 23:10:07 UTC
view on stackexchange narkive permalink

Je trouve que votre solution est terriblement contraire à l'éthique. Cela entraînera éventuellement un bug majeur parce que vous avez distrait l'équipe CR avec votre canard. Si j'avais un employé dont j'ai découvert qu'il faisait une telle chose, il serait renvoyé si vite sa tête tournerait.

Maintenant, vous avez une mauvaise situation ici. En gros, vous pourriez aussi bien ne pas faire de révision de code. La première étape pour résoudre ce problème consiste à définir des normes par écrit que tous doivent suivre, puis à les suivre. Si l'équipe CR conteste quelque chose qui est fait de la manière décrite par la norme, indiquez-lui cette norme et passez à autre chose. et ignorez cet élément d'entrée. S'ils sont corrects dans quelque chose, ajoutez cela à la norme.

L'étape suivante consiste à mieux définir le processus CR. Qu'est-ce qui est approprié et que devez-vous changer? Que devez-vous simplement commenter et ignorer. Si l'équipe et le CR ne sont pas d'accord, envoyez tout le désordre à la direction pour qu'elle se prononce dans le cadre de votre processus écrit. Alors qu'ils voient et ressentent la douleur des commentaires inutiles et du temps qu'ils doivent passer à les traiter, ils pourraient alors devenir plus sérieux pour mettre cette autre équipe en ligne. Plus le temps de gestion est perdu avec cela, plus ils comprendront. Prenez le temps d'écrire votre justification pour ignorer la demande de changement, y compris le fait que la dernière fois qu'ils voulaient A, cette fois vous leur avez donné un modèle et maintenant ce n'est pas assez bon. Ne vous inquiétez pas des retards de projet dans la réalisation de ces rapports. La direction a convenu que les retards sont moins importants que le CR, voire inutiles à ce stade. Vous voulez leur montrer à travers leur propre expérience d'avoir à faire face aux changements CR pourquoi ce n'était pas le bon choix. N'oubliez pas que le problème ici n'est pas que l'autre équipe effectue le CR. Ensuite, le problème est une gestion incompétente. Votre meilleur choix est de rendre cela suffisamment pénible pour la direction pour qu'ils finissent par se défaire et faire quelque chose.

Ensuite, pouvez-vous trouver des moyens d’affecter d’autres personnes à faire le CR en premier lieu? Cela résout complètement le problème.



Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 3.0 sous laquelle il est distribué.
Loading...