In programming, the Duck Technique is a technique whereby you place an obvious, easy oversight in your code in the hopes it will draw attention during review and mitigate large, time-consuming design changes.

There was this one team at my company well known for being very picky at review time; If we used Lib A they would want Lib B. But if we had used Lib B they'd want Lib A. They aren't happy with this design pattern and want to see a different one. But I swear if we had originally used the pattern they suggested they would have wanted the other. It was like they had to add some comment to demonstrate value. These big changes were problematic because it could turn a 1 hour task into several hours, dragging out over the course of days, blocking progress. And I know what you're thinking: why not discuss the change with that team beforehand? We did. We'd have meetings to pitch the change, explain how the design maintains backwards compatibility, and make sure they felt heard, had input, and were on board. It didn't matter. Once the code review came in it was like everything that was agreed upon was forgotten.

At one point a coworker and I had to make a change to a library we used that they owned so that we could use the modification in our program. It was a small change but we sighed, hunkered down, and just got to it, bracing for the code review. We were pair programming on the change and giving it a quick once-over before submitting for code review. Knowing this other team's tendency to be persnickety I had an idea:

Teammate: Should we replace this here with the shorthand syntax the newest version of the language introduced?

Me: Good idea...actually, leave it for now.

There were a few other instances. Nothing critical like leaving a bug but things like leaving syntax we knew the other team didn't like, leaving room for methods to be extracted or variables to be renamed. It worked beautifully. They commented on every duck, we responded with, "Thanks! Fixing now!" and that was that. Code review was over in about 10 minutes and we were able to continue on without getting blocked.

But this got me thinking, are there any ethical issues around this? I don't particularly like to do it and don't for any other team. But in this one case we were able to turn a potential 2 hour, back-and-forth code review into 10 minutes. A win in my book. I'm curious what others think or if they have alternative solutions for dealing with difficult teams.

Edit for clarity: this question keeps coming up so I wanted to address it here.

If the team is wasting everyone's time why not confront them, push back, or talk to management?

We followed all the usual/official channels first. They didn't get final say on the code review (though not getting their buy-in would have been a political lose for me) and anything that was outright dumb or dangerous we wouldn't accommodate but sometimes acquiescing to the request would save more time in the long run. I'd happily change small stuff like "spaces vs tab" or "brace placement". Larger things I'd push back on and request a reason it was worth spending time making the change. Sometimes it worked sometimes it didn't. Myself and others had approached them individually either at work or at lunch or over beers saying that these code-review-design-changes were detrimental to progress and a pain to work with. I reported their behavior as problematic to management and others may have as well.

Ideally they would be told their behavior was unacceptable, see the err of their ways, and change. But humans are not computers and don't really have to do anything the way that myself or anyone else would want to see done, regardless of how much company time and money it wasted. Any criticism could be countered with "We're not wasting time, we're making sure that the code is done the Right Way. That's certainly worth a little more time up front, isn't it?" It's not really black and white unfortunately and in the end, as I mentioned somewhere below, I decided that this was not a hill I wanted to die on. Especially because my direct interactions with this team were infrequent.

It's hard to explain besides describing it as "pickiness for the sake of pickiness". For example, we tried to automate stylistic stuff since that's a task for the editor but they would come up with convoluted rules the editor just couldn't handle consistently. I don't think they were being malicious. Stuff like, maybe one week they would really love Pattern A. Knowing this I'd make sure to use Pattern A on their code where appropriate. But at some intervening point in time they read somewhere that Pattern A is Bad and everyone should be using Pattern B. This may not get brought up in preliminary design discussions and I wouldn't think to ask because I thought they liked Pattern A but it would come up at review time. They had a strange little fiefdom and they ruled it with an iron fist but they had been at the company for a long time and management liked them. They were ultimately a nice group of people just slightly odd. It's just one of those strange work place things that probably sounds crazy unless you've run into something similar.

  • Perhaps not fully related to your main question, but why would you not be escalating this team's behaviour? If it's a common problem and you can point to actual numbers when it comes to the delays they add you might be able to pursue a more constructive option instead of working around them.
    – Lilienthal
    Mar 10 '18 at 10:18
  • Oh we pushed back. But depending on the phase of the moon they'd begrudgingly concede or fight tooth and nail. Confronting them about their behavior led to defensiveness and reporting their behavior led to strained relationships with no change in behavior. In the end this was one of the battles I decided not to pick Mar 10 '18 at 15:45
  • 2
    What are the consequences of not following their recommendations? Are they required to sign off?
    – colmde
    Mar 12 '18 at 12:37
  • @colmde I edited my question with some more details but they didn't technically have to sign off and sometimes I would push back and say, "we're going to move forward with this solution to get unblocked but can revisit in the future if you'd like" but due to their tenure at the company, doing that too much or just ignoring them would have won me some enemies. As Joe Stevens said above, sometimes it was a matter of me letting go of "doing the right thing" (reporting every instance of the behavior) and just trying to keep the peace. Mar 12 '18 at 17:58
  • @JoshJohnson What do you think their reaction would be to this if you explained what you have been doing and why? Some teams this would be a shoulder shrug and "I get it", others it would be a declaration of war.
    – Myles
    Mar 12 '18 at 22:53

Don't do that.

If someone suggests a (time-consuming) change (or many small changes) to something equivalent or worse without any justification, you should probably push back on that instead of just making the change. Review isn't (or at least shouldn't be) a one-way process where you just have to do everything the reviewer says without question, even when you have a good argument for not doing it. And, who knows, maybe they have a better argument than you think and discussing the change leads to either or both of you learning something.

If you don't just want to disagree with them (or that doesn't work), you can always try the "thanks, but no thanks" approach:

[Agree with them] You might have a good point there. [Point out problem] Although it seems like it could be a fairly time-consuming change, so we'd rather keep things the way they are for the time being, [Give reasons they can't argue with] since what we've already completed works and this allows us to focus on more pressing issues. [End on a high note] We'll definitely make a note of it and keep it in mind going forward!

Of course this wouldn't necessarily lead to them giving their approval.

If it's just some very minor changes, pushing back might not be worth the time or effort and you should probably just make the changes (unless you get a whole bunch of these with every review, and the time taken to resolve them is quickly adding up).

If someone seems compelled to give at least some feedback (however pointless or harmful) for every change, you should discuss this first with them and then with management, because they should stop doing that. I get the desire to give visibility to what you're doing (because a simple "all good" review doesn't tell anyone whether you spent a few seconds or a few hours on it), but you do that by regularly noticing subtle but substantial issues, not by wasting everyone's time with pointless feedback.

The harm in "the duck technique" is that you're now the one wasting the time of others, which could have a variety of consequences, like them missing other more important issues in your code, taking time away from their work or having this be found out and getting reprimanded.

If you've already tried all of the above ad nauseam, you've probably run out of options and you might just want to do whatever works for your unfixable review process.

  • 2
    This is the correct answer. As easy and harmless as this "duck technique" might appear, it's ultimately bad form because, if nothing else, it leaves the greater issue of "this other team is wasting everyone's time with useless feedback" unaddressed. Don't use a hack fix; solve the root cause.
    – Steve-O
    Mar 10 '18 at 21:18
  • 2
    It may seem so, but judging by the OP's follow up comments, either pushing back or reporting to management don't seem helpful, so doing the right thing may be causing more harm and time-wasting than good.
    – colmde
    Mar 12 '18 at 12:43
  • That is correct. Pushing back was generally a zero sum game with this team and they had been talked to and reported to management. The suggestion to "talk to management and have them change or be fired" keeps coming up so I edited my original question to address it in more detail. I hope that helps! Mar 12 '18 at 17:33
  • @JoshJohnson Edited. Mar 12 '18 at 18:04
  • @Dukeling thanks! [Give reasons they can't argue with] is the crux of the problem; I could find endless reasons that code needs to be changed if I wanted. And I should note that this was a one time thing. It felt like a power far too great and terrible to wield. After leaving that company I haven't run into anyone quite like them. But your answer has given me a great new perspective on the pitfalls of this "technique". Mar 12 '18 at 20:59

The only problem is not ethical but practical: if the other team ever IS in a position to contribute something useful, you have reduced the probability that you will hear about it. Otherwise, you seem totally justified in using any method to keep the code review process on track.

Does that team have an established history of providing valuable input along with their captious objections? I think the point is, even if they might do, any useful input from them is not worth plowing through heaps of sticky brown to get at.

Once the code review came in it was like everything that was agreed upon was forgotten.

This makes me think that they have ample opportunity to inject any genuine concerns into the design process, well away from the code review. This also means that it is their behavior that has driven you to manipulate the code review process.

I see no ethical grounds for censuring your use of the duck technique in this case. On the contrary, I congratulate you on the propriety of your solution.


It seems that they way your company does code reviews, and especially the way that other group does the reviews, is a an utterly rediculous waste of time. Rediculous, not ridiculous, because it's so rediculous it's not even worth spelling it right.

If I was the two groups' manager, I would be very, very angry if I find what is going on. There is nothing wrong with what you have been doing, but you shouldn't have to. I'd talk to your manager, tell him that whatever you do, they are going to want exactly the opposite, and that this is creating totally unnecessary work. Report the subterfuge that you have been using - which is also wasting time, just less. Your company is paying for all the unnecessary work. You could be doing useful things in that time. And the other group will figure out what you are doing and that will make things worse.

Your manager has to know, and your manager has to take action.

  • Thanks! And agreed. This review process is sub optimal but it was only this team that insisted upon this level of gatekeeping. Other teams were more lax and fine with whatever so long as they had visibility/input into the change, there were tests, and there were no obvious bugs or design problems. I did notify my manager who spoke with his manager and their manager and things would change temporarily but eventually revert back. Mar 10 '18 at 23:07

Work is not high school.

Let's say one of your colleagues frequently suggests small, unhelpful, changes which are changes for the sake of changes and which are slowing progress.

What you say is:

Hmm. Steve, you are frequently suggesting small, unhelpful, changes which are changes for the sake of changes and which are slowing progress.

To repeat, work is not high school.

Buckle down and get the job done!

  • 3
    Ha you're preaching to the choir. I prob should have added this in my story but the team had been reported to management by myself and others and I had approached them directly saying something similar to what you propose (though nicer). It generally led to defensiveness, a temporary cessation of nit pickyness, and then a reversion a bit later but now with strained relationships. I actually liked them but they had...odd personalities. In the end I decided I had bigger battles to fight and was willing to write off this team as something I could creatively make peace with when our paths crossed. Mar 10 '18 at 22:33
  • 1
    heh good one @JoshJohnson - totally understood
    – Fattie
    Mar 12 '18 at 23:44
  • 2
    Work is not high school Unfortunately, it can be a lot more like high school than we would like. In particular, social hierarchies have real power. Especially if Steve is more senior than you, telling him his suggestions are unhelpful can just result in an argument and/or him going on at length about why you are wrong and his suggestions are important to follow.
    – jhocking
    Jun 19 '18 at 16:40
  • hi @jhocking - your example is regarding someone superior to you at work. this QA is about colleagues. (Regarding superiors, I agree with you completely. (1) do precisely what they say at all times, with no discussion and a positive attitude or (2) start your own company. That's just how it is. :/ )
    – Fattie
    Jun 19 '18 at 17:06

I find your solution to be horrifyingly unethical. It will eventually result in a major bug going through because you distracted the CR team with your duck. If I had an employee that I found out was doing such a thing, he would be fired so fast his head would spin.

Now granted you have a bad situation here. Basically you might as well not be doing code review. First step to fix it is to set out standards in writing that all must follow and then follow them. If the CR team objects to something done the way the standard describes, then point to that standard and move on and ignore that piece of input. If they are correct in something, add that to the standard.

Next step is to define the CR process better. What is appropriate and what must you change vice what do you simply have to comment on and ignore. If the team and the CR disagree, then send the whole mess to management to adjudicate as part of your written process. As they see and feel the pain of the unnecessary comments and the time they have to spend dealing with them, then they might get more serious about getting this other team into line. The more management time is wasted with this, the more they will understand. Take the time to write up your justification for ignoring the change request including, the fact that the last time they wanted A, so this time you gave them pattern a and now that isn't good enough. Don;t worry about project delays in doing these write-ups. Management has agreed that delays are less important the CR even pointless CR at this point. You want to show them through their own experience of having to deal with the CR changes why that was the wrong choice. Remember the problem here is not the other team doing the CR. Then problem is incompetent management. Your best choice is to make this painful enough for management that they finally get off their butts and do something about it.

Next can you find ways to assign other people to do the CR in the first place? This completely solves the problem.

Not the answer you're looking for? Browse other questions tagged .