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.