Ethik der "Ententechnik" [geschlossen]

Bei der Programmierung ist die Duck-Technik eine Technik, bei der Sie Ihren Code offensichtlich und leicht übersehen, in der Hoffnung, dass er während der Überprüfung Aufmerksamkeit erregt und große, zeitaufwändige Designänderungen abmildert.

In meiner Firma gab es dieses eine Team, das dafür bekannt war, bei der Überprüfung sehr wählerisch zu sein; Wenn wir Lib A verwendet hätten, würden sie Lib B wollen. Aber wenn wir Lib B benutzt hätten, hätten sie Lib A wollen. Sie sind mit diesem Designmuster nicht zufrieden und wollen ein anderes sehen. Aber ich schwöre, wenn wir ursprünglich das von ihnen vorgeschlagene Muster verwendet hätten, hätten sie das andere gewollt. Es war, als müssten sie etwas hinzufügenKommentar, um den Wert zu demonstrieren. Diese großen Änderungen waren problematisch, da sie eine 1-stündige Aufgabe in mehrere Stunden verwandeln konnten, sich über Tage hinzogen und den Fortschritt blockierten. Und ich weiß, was Sie denken: Warum besprechen Sie die Änderung nicht vorher mit diesem Team? Wir machten. Wir würden Meetings abhalten, um die Änderung vorzustellen, zu erklären, wie das Design die Abwärtskompatibilität aufrechterhält, und sicherzustellen, dass sie sich gehört fühlen, Input haben und an Bord sind. Es spielte keine Rolle. Als die Codeüberprüfung eintraf, war es, als wäre alles, was vereinbart wurde, vergessen worden.

Irgendwann mussten ein Kollege und ich eine Änderung an einer von uns verwendeten Bibliothek vornehmen, die ihnen gehörte, damit wir die Änderung in unserem Programm verwenden konnten. Es war eine kleine Änderung, aber wir seufzten, duckten uns und machten uns einfach daran, um uns auf die Codeüberprüfung vorzubereiten. Wir programmierten die Änderung zu zweit und überprüften sie kurz, bevor wir sie zur Codeüberprüfung einreichten. Da ich die Tendenz dieses anderen Teams zur Spitzfindigkeit kannte, hatte ich eine Idee:

Teamkollege: Sollen wir das hier durch die Kurzform der neusten Version der eingeführten Sprache ersetzen?

Ich: Gute Idee ... eigentlich, lass es jetzt.

Es gab noch ein paar andere Fälle. Nichts Wichtiges wie das Hinterlassen eines Fehlers, aber Dinge wie das Hinterlassen einer Syntax, von der wir wussten, dass sie dem anderen Team nicht gefiel, und das Freilassen von Raum für das Extrahieren von Methoden oder das Umbenennen von Variablen. Es hat wunderbar funktioniert. Sie kommentierten jede Ente, wir antworteten mit: „Danke! Jetzt reparieren!“ und das war es. Die Codeüberprüfung war in etwa 10 Minuten beendet und wir konnten weitermachen, ohne blockiert zu werden.

Aber das brachte mich zum Nachdenken, gibt es irgendwelche ethischen Probleme in dieser Hinsicht? Ich mache das nicht besonders gerne und auch nicht für andere Teams. Aber in diesem einen Fall konnten wir eine mögliche 2-stündige Codeüberprüfung in 10 Minuten umwandeln. Ein Gewinn in meinem Buch. Ich bin gespannt, was andere denken oder ob sie alternative Lösungen für den Umgang mit schwierigen Teams haben.

Bearbeiten Sie zur Verdeutlichung: Diese Frage taucht immer wieder auf, also wollte ich sie hier ansprechen.

Wenn das Team die Zeit aller verschwendet, warum sollte man sie nicht konfrontieren, zurückdrängen oder mit dem Management sprechen?

Wir folgten zuerst allen üblichen/offiziellen Kanälen. Sie hatten kein letztes Wort bei der Codeüberprüfung (obwohl es für mich ein politischer Verlust gewesen wäre, ihre Zustimmung nicht zu erhalten) und alles, was absolut dumm oder gefährlich war, würden wir nicht berücksichtigen, aber manchmal würde es mehr sparen, wenn wir der Bitte nachgeben würden Zeit auf lange Sicht. Kleine Dinge wie "Leerzeichen vs. Tabulator" oder "Klammernplatzierung" würde ich gerne ändern. Größere Dinge würde ich zurückdrängen und nach einem Grund fragen, warum es sich gelohnt hat, Zeit für die Änderung aufzuwenden. Mal hat es geklappt mal nicht. Ich selbst und andere hatten sie einzeln angesprochen, entweder bei der Arbeit, beim Mittagessen oder bei einem Bier, und gesagt, dass diese Code-Review-Design-Änderungen dem Fortschritt abträglich seien und es mühsam wäre, damit zu arbeiten. Ich habe ihr Verhalten dem Management als problematisch gemeldet, und andere haben es möglicherweise auch getan.

Im Idealfall würde ihnen gesagt werden, ihr Verhalten sei inakzeptabel, sie würden ihre Fehler einsehen und sich ändern. Aber Menschen sind keine Computer und müssen nichts so tun, wie ich oder andere es gerne hätten, unabhängig davon, wie viel Zeit und Geld das Unternehmen verschwendet. Jeglicher Kritik könnte mit „Wir verschwenden keine Zeit, wir stellen sicher, dass der Code richtig gemacht wird. Es ist leider nicht wirklich schwarz und weiß und am Ende entschied ich, wie ich irgendwo unten erwähnte, dass dies kein Hügel war, auf dem ich sterben wollte. Vor allem, weil meine direkten Interaktionen mit diesem Team selten waren.

Es ist schwer zu erklären, außer es als "Pickiness um der Pickiness willen" zu beschreiben. Zum Beispiel haben wir versucht, stilistische Dinge zu automatisieren, da dies eine Aufgabe für den Redakteur ist, aber sie kamen auf verworrene Regeln, die der Redakteur einfach nicht konsequent handhaben konnte. Ich glaube nicht, dass sie böswillig waren. Sachen wie, vielleicht würden sie Muster A in einer Woche wirklich lieben. Wenn ich das weiß, würde ich sicherstellen, Muster A in ihrem Code zu verwenden, wo es angebracht ist. Aber irgendwann haben sie irgendwo gelesen, dass Muster A schlecht ist und jeder Muster B verwenden sollte. Dies wird in vorläufigen Designdiskussionen möglicherweise nicht zur Sprache gebracht, und ich würde nicht daran denken, zu fragen, weil ich dachte, dass ihnen Muster A gefallen würde, aber es würde zur Überprüfungszeit kommen. Sie hatten ein seltsames kleines Lehen und regierten es mit eiserner Faust, aber sie waren schon lange in der Firma und das Management mochte sie. Sie waren letztendlich eine nette Gruppe von Menschen, nur etwas seltsam. Es ist nur eines dieser seltsamen Dinge am Arbeitsplatz, die wahrscheinlich verrückt klingen, es sei denn, Sie sind auf etwas Ähnliches gestoßen.

Vielleicht nicht ganz auf Ihre Hauptfrage bezogen, aber warum sollten Sie das Verhalten dieses Teams nicht eskalieren? Wenn es sich um ein häufiges Problem handelt und Sie auf tatsächliche Zahlen zu den hinzugefügten Verzögerungen verweisen können, können Sie möglicherweise eine konstruktivere Option verfolgen, anstatt sie zu umgehen.
Oh, wir haben zurückgedrängt. Aber je nach Mondphase gaben sie widerwillig nach oder kämpften mit Händen und Füßen. Sie mit ihrem Verhalten zu konfrontieren, führte zu Abwehrhaltung, und das Melden ihres Verhaltens führte zu angespannten Beziehungen ohne Verhaltensänderung. Am Ende war dies einer der Kämpfe, die ich entschieden habe, nicht zu wählen
Welche Folgen hat es, wenn man ihren Empfehlungen nicht folgt? Müssen sie sich abmelden?
@colmde Ich habe meine Frage mit einigen weiteren Details bearbeitet, aber sie mussten sich technisch nicht abmelden, und manchmal habe ich zurückgedrängt und gesagt: „Wir werden mit dieser Lösung fortfahren, um die Blockierung aufzuheben, können sie aber in Zukunft erneut besuchen, wenn Sie möchten", aber aufgrund ihrer Anstellung in der Firma hätte ich mir einige Feinde eingebracht, wenn ich das zu oft getan oder sie einfach ignoriert hätte. Wie Joe Stevens oben sagte, ging es mir manchmal darum, „das Richtige zu tun“ (jeden Fall des Verhaltens zu melden) loszulassen und einfach zu versuchen, den Frieden zu wahren.
@JoshJohnson Was denkst du, wie ihre Reaktion darauf wäre, wenn du erklären würdest, was du getan hast und warum? Bei manchen Teams wäre das ein Schulterzucken und „Ich verstehe“, bei anderen eine Kampfansage.
Wenn Sie eine Vorabgenehmigung für Dinge wie Bibliotheken erhalten, erstellen Sie ein Projektumfangsdokument, das sie definiert. Alle beteiligten Parteien würden das Dokument abzeichnen, und wenn das Problem später bei der Überprüfung auftritt, könnten Sie einfach auf das Dokument verweisen. Das Ändern einer Bibliothek kann eine massive Änderung sein.
@Myles Dies war eine einmalige Sache und keine gängige Praxis, so dass sich die Dinge etwas ändern können (oder auch nicht). Wenn ich mir vorstelle, dass jemand mir das antut und mir dann davon erzählt, würde ich lachen, dass meine Vorlieben so vorhersehbar waren, und dann meine Werte in Bezug auf CR neu bewerten, obwohl mein jüngeres Ich vielleicht empört war. Für sie hätte ich mir vorstellen können, dass sie sich gekränkt gefühlt hätten und es einer Kriegserklärung näher gekommen wäre. Aber ich könnte mir auch vorstellen, all die Jahre später bei einem Drink mit ihnen darüber zu lachen. Schwer zu erzählen. Guter Einblick, danke

Antworten (5)

Tu das nicht.

Wenn jemand ohne Begründung eine (zeitaufwändige) Änderung (oder viele kleine Änderungen) zu etwas Äquivalentem oder Schlechterem vorschlägt, sollten Sie dies wahrscheinlich zurückdrängen, anstatt nur die Änderung vorzunehmen. Die Überprüfung ist kein einseitiger Prozess (oder sollte es zumindest nicht sein), bei dem Sie einfach alles tun müssen, was der Überprüfer sagt, ohne zu hinterfragen, selbst wenn Sie gute Argumente dafür haben, dies nicht zu tun. Und wer weiß, vielleicht haben sie ein besseres Argument als Sie denken, und die Diskussion über die Änderung führt dazu, dass einer oder beide von Ihnen etwas lernen.

Wenn Sie ihnen nicht nur widersprechen wollen (oder das nicht funktioniert), können Sie immer den „Danke, aber nein danke“-Ansatz ausprobieren:

[stimme ihnen zu] Da hast du vielleicht einen guten Punkt. [Problem hervorheben] Obwohl es scheint, dass es eine ziemlich zeitaufwändige Änderung sein könnte, würden wir die Dinge vorerst lieber so lassen, wie sie sind, [geben Sie Gründe an, mit denen sie nicht streiten können], seit dem, was wir haben bereits abgeschlossene Arbeiten, wodurch wir uns auf dringendere Probleme konzentrieren können. [Ende auf einer hohen Note] Wir werden es auf jeden Fall notieren und für die Zukunft im Hinterkopf behalten!

Das würde natürlich nicht zwangsläufig zu einer Zustimmung führen.

Wenn es sich nur um einige sehr geringfügige Änderungen handelt, lohnt sich das Zurückschieben möglicherweise nicht und Sie sollten die Änderungen wahrscheinlich einfach vornehmen (es sei denn, Sie erhalten bei jeder Überprüfung eine ganze Reihe davon und die Zeit, die für die Lösung benötigt wird, summiert sich schnell ).

Wenn jemand gezwungen zu sein scheint, für jede Änderung zumindest ein Feedback zu geben (wie sinnlos oder schädlich auch immer), sollten Sie dies zuerst mit ihm und dann mit dem Management besprechen, da er damit aufhören sollte. Ich bekomme den Wunsch, sichtbar zu machen, was Sie tun (weil eine einfache „Alles-gut“-Rezension niemandem sagt, ob Sie ein paar Sekunden oder ein paar Stunden damit verbracht haben), aber Sie tun dies, indem Sie regelmäßig ein subtiles Aber bemerken wesentliche Probleme, nicht indem Sie die Zeit aller mit sinnlosem Feedback verschwenden.

Der Nachteil der "Ententechnik" besteht darin, dass Sie jetzt derjenige sind, der die Zeit anderer verschwendet, was eine Vielzahl von Konsequenzen haben kann, z herausgefunden und gerügt werden.

Wenn Sie alle oben genannten Punkte bereits bis zum Erbrechen ausprobiert haben, sind Ihnen wahrscheinlich die Optionen ausgegangen, und Sie möchten vielleicht einfach das tun, was für Ihren nicht reparierbaren Überprüfungsprozess funktioniert.

Dies ist die richtige Antwort. So einfach und harmlos diese „Ententechnik“ auch erscheinen mag, sie ist letztlich ein schlechter Stil, weil sie nicht zuletzt das größere Problem „dieses andere Team verschwendet die Zeit aller mit nutzlosem Feedback“ unberücksichtigt lässt. Verwenden Sie keinen Hack-Fix; die Grundursache lösen.
Es mag so scheinen, aber nach den Folgekommentaren des OP zu urteilen, scheint es nicht hilfreich zu sein, entweder zurückzudrängen oder sich an das Management zu melden, so dass das Richtige zu tun möglicherweise mehr Schaden und Zeitverschwendung anrichtet als nützt.
Das ist richtig. Zurückdrängen war im Allgemeinen ein Nullsummenspiel mit diesem Team, und sie waren mit dem Management gesprochen und dem Management gemeldet worden. Der Vorschlag, „mit dem Management zu sprechen und sie wechseln oder feuern zu lassen“, taucht immer wieder auf, also habe ich meine ursprüngliche Frage bearbeitet, um sie detaillierter zu behandeln. Ich hoffe das hilft!
@JoshJohnson Bearbeitet.
@Dukeling danke! [Give reasons they can't argue with]ist der Kern des Problems; Ich könnte endlose Gründe finden, warum der Code geändert werden muss, wenn ich wollte. Und ich sollte anmerken, dass dies eine einmalige Sache war. Es fühlte sich wie eine Macht an, die viel zu groß und schrecklich war, um sie einzusetzen. Nachdem ich diese Firma verlassen hatte, habe ich niemanden wie sie getroffen. Aber Ihre Antwort hat mir eine großartige neue Perspektive auf die Fallstricke dieser "Technik" gegeben.
Ein weiteres Risiko bei der „Duck-Technik“ besteht darin, dass absichtlich Fehler/schlechter Code hinzugefügt werden, um Fehler/schlechten Code hinzuzufügen . Was passiert, wenn das Überprüfungsteam die Ente irgendwie verfehlt? Was ist, wenn Sie vergessen, die Ente zu entfernen, nachdem sie verfehlt wurde? Jetzt haben Sie Fehler in Ihrem Code, die eigentlich gar nicht vorhanden sein sollten.

Das einzige Problem ist nicht ethisch, sondern praktisch: Wenn das andere Team jemals in der Lage ist, etwas Nützliches beizutragen, haben Sie die Wahrscheinlichkeit verringert, dass Sie davon erfahren. Andernfalls scheinen Sie völlig berechtigt zu sein, irgendeine Methode zu verwenden, um den Codeüberprüfungsprozess auf Kurs zu halten.

Verfügt dieses Team über eine etablierte Geschichte der Bereitstellung wertvollen Inputs zusammen mit seinen wortkargen Einwänden? Ich denke, der Punkt ist, selbst wenn sie es könnten, jeder nützliche Input von ihnen ist es nicht wert, durch Haufen von klebrigem Braun zu pflügen, um an ihn heranzukommen.

Als die Codeüberprüfung eintraf, war es, als wäre alles, was vereinbart wurde, vergessen worden.

Das lässt mich denken, dass sie reichlich Gelegenheit haben, echte Bedenken in den Designprozess einzubringen, weit weg von der Codeüberprüfung. Das bedeutet auch, dass es ihr Verhalten war, das Sie dazu veranlasst hat, den Codeüberprüfungsprozess zu manipulieren.

Ich sehe keinen ethischen Grund, Ihre Verwendung der Ententechnik in diesem Fall zu tadeln. Im Gegenteil, ich gratuliere Ihnen zur Korrektheit Ihrer Lösung.

Es scheint, dass die Art und Weise, wie Ihr Unternehmen Code-Reviews durchführt, und insbesondere die Art und Weise, wie andere Gruppen die Reviews durchführen, eine absolut lächerliche Zeitverschwendung ist. Lächerlich, nicht lächerlich, weil es so lächerlich ist, dass es sich nicht einmal lohnt, es richtig zu schreiben.

Wenn ich der Manager der beiden Gruppen wäre, wäre ich sehr, sehr wütend, wenn ich herausfinde, was los ist. Es ist nichts falsch an dem, was du getan hast, aber du solltest es nicht müssen. Ich würde mit Ihrem Vorgesetzten sprechen und ihm sagen, dass er genau das Gegenteil will, was immer Sie tun, und dass dies völlig unnötige Arbeit verursacht. Melden Sie die Ausflucht, die Sie benutzt haben - was auch Zeitverschwendung ist, nur weniger. Ihr Unternehmen zahlt für all die unnötige Arbeit. Sie könnten in dieser Zeit nützliche Dinge tun. Und die andere Gruppe wird herausfinden, was Sie tun, und das wird die Dinge noch schlimmer machen.

Ihr Vorgesetzter muss es wissen, und Ihr Vorgesetzter muss handeln.

Danke! Und zugestimmt. Dieser Überprüfungsprozess ist suboptimal, aber nur dieses Team hat auf diesem Grad an Gatekeeping bestanden. Andere Teams waren lockerer und feiner mit allem, solange sie Einblick in die Änderung hatten, es Tests gab und es keine offensichtlichen Fehler oder Designprobleme gab. Ich habe meinen Vorgesetzten benachrichtigt, der mit seinem Vorgesetzten und seinem Vorgesetzten gesprochen hat, und die Dinge würden sich vorübergehend ändern, aber schließlich wieder zurückkehren.

Arbeit ist nicht Highschool.

Angenommen, einer Ihrer Kollegen schlägt häufig kleine, nicht hilfreiche Änderungen vor, die Änderungen um der Änderungen willen sind und den Fortschritt verlangsamen.

Was du sagst ist:

Hmm. Steve, Sie schlagen häufig kleine, nicht hilfreiche Änderungen vor, die Änderungen um der Änderungen willen sind und den Fortschritt verlangsamen.

Um es noch einmal zu wiederholen: Arbeit ist nicht Highschool .

Schnallen Sie sich an und erledigen Sie die Arbeit!

Ha, du predigst dem Chor. Ich hätte das wahrscheinlich in meiner Geschichte hinzufügen sollen, aber das Team wurde von mir und anderen dem Management gemeldet, und ich bin direkt auf sie zugekommen und habe etwas Ähnliches gesagt, wie Sie es vorgeschlagen haben (wenn auch netter). Es führte im Allgemeinen zu Abwehrhaltung, einem vorübergehenden Ende der Spitzfindigkeit und dann etwas später zu einer Umkehr, aber jetzt mit angespannten Beziehungen. Ich mochte sie eigentlich, aber sie hatten ... seltsame Persönlichkeiten. Am Ende entschied ich, dass ich größere Schlachten zu kämpfen hatte und war bereit, dieses Team als etwas abzuschreiben, mit dem ich kreativ Frieden schließen konnte, wenn sich unsere Wege kreuzten.
heh gut @JoshJohnson - total verstanden
Work is not high schoolLeider kann es viel mehr wie die High School sein, als wir möchten. Insbesondere soziale Hierarchien haben echte Macht. Besonders wenn Steve älter ist als Sie, kann es nur zu einem Streit führen, wenn Sie ihm sagen, dass seine Vorschläge nicht hilfreich sind, und / oder er ausführlich darüber redet, warum Sie falsch liegen und seinen Vorschlägen unbedingt folgen sollten.
Hallo @jhocking - Ihr Beispiel bezieht sich auf jemanden , der Ihnen bei der Arbeit überlegen ist. Bei dieser QA geht es um Kollegen. (In Bezug auf Vorgesetzte stimme ich Ihnen vollkommen zu. (1) Immer genau das tun, was sie sagen, ohne Diskussion und mit einer positiven Einstellung, oder (2) ein eigenes Unternehmen gründen. So ist es eben. :/ )

Ich finde Ihre Lösung erschreckend unethisch. Es wird schließlich zu einem großen Fehler führen, weil Sie das CR-Team mit Ihrer Ente abgelenkt haben. Wenn ich einen Angestellten hätte, von dem ich herausfand, dass er so etwas tut, würde er so schnell gefeuert werden, dass ihm der Kopf schwirrt.

Nun, zugegeben, Sie haben hier eine schlechte Situation. Grundsätzlich können Sie auch keine Codeüberprüfung durchführen. Der erste Schritt, um dies zu beheben, besteht darin, Standards schriftlich festzulegen, die alle befolgen müssen, und ihnen dann zu folgen. Wenn das CR-Team Einwände dagegen hat, dass etwas so gemacht wird, wie es der Standard beschreibt, dann zeigen Sie auf diesen Standard und fahren Sie fort und ignorieren Sie diesen Beitrag. Wenn sie in etwas richtig sind, fügen Sie das dem Standard hinzu.

Der nächste Schritt besteht darin, den CR-Prozess besser zu definieren. Was ist angemessen und was müssen Sie ändern, was müssen Sie einfach kommentieren und ignorieren. Wenn das Team und der CR anderer Meinung sind, senden Sie das ganze Chaos an das Management, um es im Rahmen Ihres schriftlichen Prozesses zu entscheiden. Wenn sie den Schmerz der unnötigen Kommentare und die Zeit, die sie damit verbringen müssen, damit umzugehen, sehen und fühlen, werden sie möglicherweise ernsthafter daran denken, dieses andere Team auf Linie zu bringen. Je mehr Verwaltungszeit damit verschwendet wird, desto mehr werden sie verstehen. Nehmen Sie sich die Zeit, Ihre Begründung für das Ignorieren der Änderungsanforderung aufzuschreiben, einschließlich der Tatsache, dass sie das letzte Mal A wollten, also haben Sie ihnen diesmal Muster a gegeben, und das ist jetzt nicht gut genug. Machen Sie sich bei diesen Zuschreibungen keine Sorgen über Projektverzögerungen. Das Management hat zugestimmt, dass Verzögerungen weniger wichtig sind, sogar sinnlose CR an dieser Stelle. Sie wollen ihnen durch ihre eigene Erfahrung im Umgang mit den CR-Veränderungen zeigen, warum das die falsche Wahl war.Denken Sie daran, dass das Problem hier nicht darin besteht, dass das andere Team die CR durchführt. Dann ist das Problem inkompetentes Management. Ihre beste Wahl ist, dies für das Management so schmerzhaft zu machen, dass sie endlich ihren Hintern hochbekommen und etwas dagegen unternehmen.

Können Sie als Nächstes Möglichkeiten finden, andere Personen überhaupt mit CR zu beauftragen? Dies löst das Problem vollständig.

Ethik der "Ententechnik" [geschlossen]
AntwortenHierDatenschutz-Bestimmungen1y, 0v