“Just remove the duck” (2013)

A story from the time recounts that Piero Soderino, the head of the powerful Florentine Republic, even told the famously irascible Michelangelo that David&#x27;s nose was much too large. Michelangelo then hid some marble dust in his hand, climbed back up his ladder and pretended to do some more &quot;chiseling&quot; on the offending proboscis. While he did so, he let some marble dust fall from his hand. The pompous Soderino was fooled – he examined the unchanged nose and announced it was much improved and far more &quot;life-like.&quot;<p><a href="http://www.globusjourneys.com/travel-stories/italy/michelangelos-david/" rel="nofollow">http:&#x2F;&#x2F;www.globusjourneys.com&#x2F;travel-stories&#x2F;italy&#x2F;michelang...</a>

I&#x27;m reminded of a blog post by an old govvie that hated this approach. His argument was that every time we work around a problem in our process, whether it was a bad system or an incompetent co-worker or manager, we became the problem. Every time we added a duck or built a workaround we were building frameworks that would hold a bad policy in place for longer than if we just stopped and said &quot;that&#x27;s stupid&quot;. Adding the duck binds your co-workers and successors to a life of misery.<p>There&#x27;s a real risk (of course) to killing the duck. Your client or your boss may hate you, and that&#x27;s never healthy in the short run, but they also may come out of the interaction a wiser and better person. Or you may find yourself not working for an idiot, and be happier in the long run anyways. Keeping the duck alive is a bigger long-term risk for everyone.<p>Kill the duck.

I hate this story.<p>I think it&#x27;s important to differentiate between people who have the right knowledge to request a change and those that think they have the right solely because of seniority; but it&#x27;s also rather disrespectful to &#x27;cheat&#x27; and make fake changes just to make the someone happy. No-one deserves to be treated like a &#x27;mark&#x27; for our tricks.<p>My experience has been that being honest, polite and knowledgeable is a much better approach.

Putting on my client&#x2F;product manager hat for a moment, this is incredibly annoying. You are putting me in the position of either (a) fixing the obvious ducks and not looking closely at the real problems, or (b) having to micromanage you and scheduling another review to make further changes. Maybe you get your desired result (a), but my opinion of your work is going to be much lower since you are making obvious duck-sized mistakes.<p>If you are a developer who takes this approach, you may want to consider whether the short-term benefit of avoiding criticism is worth the long-term downside of having me think you are incompetent.

I once talked to an SAP consultant, and he told me he would often make some part of his code painfully slow on intention. So during review meetings, rather than endlessly discuss minute details and demanding arbitrary changes, people would complain about how slow it was. &quot;I&#x27;ll see what I can do&quot;, the guy would sigh, go to his office, remove the offending code, and voila - everyone was happy.<p>I haven&#x27;t had the opportunity to try this technique, but I have been waiting ever since for the moment where this might come in handy.

This is classic military when presenting anything to an officer for review. I&#x27;ve definitely read references of it going back to WWII (intentional, obvious oil smudge on otherwise pristine rifle). It was frequently stated that no officer could leave a document unedited after review, so an obvious misspelling or two would be added. It&#x27;s a way of life on the military, really.

Dilbert has this covered: <a href="http://dilbert.com/strip/2007-02-02" rel="nofollow">http:&#x2F;&#x2F;dilbert.com&#x2F;strip&#x2F;2007-02-02</a>

I worked at a deli during college, and people did this same type of thing on slices. By default, I&#x27;d always pick a pretty thin slice. Most people really like thinly sliced meats. The first thing you do is slice once and show them the slice, making sure it fits what they wanted. 99% of the time, people would say &quot;thinner,&quot; I would pretend to fiddle with the knob, slice the same thickness, and they&#x27;d say &quot;perfect!&quot;<p>I think it gives them some sort of feeling of control and ownership over what is happening.

Funny how she mentions dogs.<p>In Dutch it is a common expression to say something like &quot;And then of course he has to pee on it a bit&quot;. (Hij moet daar nog even een plasje over doen) to indicate exactly this behaviour.

I guess this is probably the story she&#x27;s referring to: <a href="http://blog.codinghorror.com/new-programming-jargon/" rel="nofollow">http:&#x2F;&#x2F;blog.codinghorror.com&#x2F;new-programming-jargon&#x2F;</a>

There&#x27;s a certain tone in this article that bothers me a bit.<p>At least in software engineering, the idea of reviews is to find errors in code or design how ever small they are. When inspecting any code, we almost always find at least something, regardless of the level of quality. It&#x27;s not about being fair, it&#x27;s not personal, and it probably isn&#x27;t even dependent on the reviewers personality. It&#x27;s just that when the goal is to find deviations, that&#x27;s what happens. It&#x27;s just a process. The errors may be small or big, it doesn&#x27;t matter, we just need to find them.<p>Some inexperienced developers often find the code review process intimidating and unfair. They take it personally. That&#x27;s a wrong attitude.

There was a similar story, that I can&#x27;t now find a source for, of an advertising company that regularly added a &#x27;helicopter&#x27; into their customer quotes for video shots. As well as being superfluous it was massively expensive. So the customers say &#x27;we don&#x27;t need a helicopter&#x27;, strike that out and feel good that they&#x27;ve done their cost cutting. The rest of the plan makes it through unscathed.

NPR had a story about this in graphic design where it has the term &quot;Hairy Arms&quot;: <a href="http://www.npr.org/2014/11/17/364760847/whats-with-all-of-the-hairy-arms-in-graphic-design" rel="nofollow">http:&#x2F;&#x2F;www.npr.org&#x2F;2014&#x2F;11&#x2F;17&#x2F;364760847&#x2F;whats-with-all-of-th...</a>

Battle Chess was a great game. I believe I recall the rook eating the queen as well.

This is also great parenting advice. Give your kid the feeling of having chosen to eat their vegetables, and they&#x27;ll devour an entire plate of them.

I&#x27;m guilty of doing this quite often. My boss wants to make some amends everytime we review my task. Earlier I used to try to make the result as perfect as possible which resulted in him asking me to make significant changes which are unwarranted. Now I intentionally leave a minor correction which I&#x27;m sure he will notice. So now he gets the satisfaction of finding something in review while I still get to maintain the application the way I wanted it to be. Win-win?

I have routinely left known performance optimization tasks to be done after the initial review of a product&#x27;s MVP features. It just seemed better to get the first cut out to people to review in case significant refactoring occurred in response to the first round of feedback.<p>The unintended consequence of this approach is that changes in response to feedback appeared to have much more impact on the overall UX experience. It increased reviewers&#x27; feeling of ownership of the product and they were more likely to become product champions and evangelists.

You&#x27;d be surprised how many standards are made like this. Companies adding useless stuff due to political reasons, appending obfuscating things so that somebody can claim credit for that part of the standard, hiding the real agenda they want to pass, proposing exact opposites to what they want so that others stop their (ridiculous) idea in order not to give them any advantage that sometimes backfires and ends up in the standard anyway (but they would do it even for reasonable idea as they don&#x27;t want to make life easy for a competitor), other companies blocking anything they consider a strategic threat to the way they do their business, and you&#x27;ll end up with a horrible standard full of ducks and hairy hands... Add to it occasional groupthink and dyslexia and then wonder why most software standards are so horrible...

I&#x27;ve never intentionally added something that I used as a distraction from the rest of the work, but I have added requested features--that I thought were poor design--in a way that would be very easy to remove. Later, when the client finally agrees that it is a bad feature, it&#x27;s no trouble to remove it.<p>I&#x27;ve also just hidden things that the client has asked removed if I thought they would eventually ask for it again, once they got to using the software. They usually do, and they think I&#x27;m a &quot;genius&quot; when I can make these &quot;big&quot; changes in such short periods of time.<p>Hell, I even tell them I&#x27;m going to do it. I&#x27;m always very forthright with my clients. But they never remember. They always think I do everything from scratch. I guess because their own developers do, they think we all work the same way.

Similarly, always give options, subtly worse than the one you want to see picked. See Dan Ariely&#x27;s books.

An electrical engineer I worked with told me about a similar situation he had encountered at a previous job.<p>He would design a circuit only to have another engineer (responsible for cost cutting), remove or modify a component. The resulting design would not work as well.<p>To get around this, he would add some sacrificial extra component like a resistor. The cost cutter would remove this leaving the original design intact.

Similar thing was often done by writers in the Eastern bloc to fool the censors. They left some obviously bad things in the material to be censored, so the censor could complain about something, and they would leave more subtle references intact.

I think a lot if this effect is just that people think differently from each other.<p>Eventually, someone is going to see something you did, where they would have done it a different way. If that person is your manager, not only do they see lots of things you are doing (and thus plenty of things they might have done differently) they also have the power to compel you to do it their way.<p>If you&#x27;re the boss, presumable you think you are the boss because someone higher up still thinks you do a good job, which is a sort of implicit endorsement for you doing things your way, instead of your subordinates way.

I have thought about the same tactic if you are selling your house, and the potential buyer is bringing an inspector.<p>&quot;Break&quot; three things in your house, e.g., remove the cover from a bathroom exhaust fan, loosen a faucet so that it rattles, and remove all of the light bulbs from an overhead fixture. The inspector will find these, the buyers will require that they be fixed, and it will be easy for you to do so.<p>If you don&#x27;t do this, the inspector will find three other things.<p>Of course this would only work if your house doesn&#x27;t need any significant work done in the first place.

We, as engineers, should also resist the temptation to leave our own mark when we&#x27;re reviewing products designed by others. I don&#x27;t work in management, but I&#x27;ve been in review meetings and I have made suggestions that worked their way into the final product. I like to think that my own suggestions were helpful, but it is gratifying to see one&#x27;s own suggestion implemented. The temptation to leave one&#x27;s mark just for its own sake is something we should all be aware of.

For lawyers drafting contracts, there&#x27;s a quite-legitimate, signaling-related reason for &quot;doing the duck.&quot; By giving the other side&#x27;s contract reviewer something to object to and revise, <i>it lets her demonstrate to her boss that she did her job competently.</i> For example, she can then report to her boss (or client), &quot;they wanted net 15 days payment terms but I made them change it to net 30; otherwise it was an OK contract.&quot; That in turn can help get the contract out of legal review, and into the signature process, more quickly.<p>This is sort of related to the story about Van Halen&#x27;s concert contract that required a bowl of M&amp;Ms in the dressing room with all brown M&amp;Ms removed. [1]<p>[1] <a href="http://www.snopes.com/music/artists/vanhalen.asp" rel="nofollow">http:&#x2F;&#x2F;www.snopes.com&#x2F;music&#x2F;artists&#x2F;vanhalen.asp</a>

How much of our work in this business is just useless theater?<p>I couldn&#x27;t stand working in a place where it was a significant portion of work. But it is probably unavoidable to some degree.<p>I see that code reviews for newcomers&#x27; commits often have these elements:<p>First review: &quot;you did X. That&#x27;s not smart. Do Y instead.&quot;<p>The new employee goes back to rework their commit.<p>Second review: &quot;you did Y. That&#x27;s not smart. Do X instead.&quot;<p>After a few weeks &#x2F; months it starts getting reasonable. It&#x27;s not as extreme, and it&#x27;s well disguised in friendly demeanor, but there&#x27;s still some similarities to what it was like in the army &quot;boot camp&quot;.

It&#x27;s not about leaving your mark, it&#x27;s about posturing. I used to work in a kitchen. At the end of the night the manager would do a walk through and always find something not to their liking that needed to be finished before you went home. Sometimes it would be simple, sometimes it took a long time. I got in the habit of leaving something simple and obvious, like a splotch of mayo on the counter, and it resolved the issue.

It&#x27;s not uncommon, in business dealings or in legal contracts, to put things in that you know the other side will remove just in order to make them feel as if &quot;money hasn&#x27;t been left on the table&quot; or that they have done their job for their client. You almost have to do that as part of negotiation to get what you want and to satisfy all parties many times.

[Here&#x27;s the link to the Stack Exchange post](<a href="http://programmers.stackexchange.com/questions/122009/developing-a-feature-which-sole-purpose-to-be-taken-out" rel="nofollow">http:&#x2F;&#x2F;programmers.stackexchange.com&#x2F;questions&#x2F;122009&#x2F;develo...</a>) (on the Programmers site) that&#x27;s reverenced in the blog post.

This reminds me of &quot;How a Web Design Goes Straight to Hell&quot; [1] by The Oatmeal. It&#x27;s a different moral, of course; basically, don&#x27;t trust the client more than you need to.<p>[1] <a href="http://theoatmeal.com/comics/design_hell" rel="nofollow">http:&#x2F;&#x2F;theoatmeal.com&#x2F;comics&#x2F;design_hell</a>

&gt;&gt; The sacrificial duck kept the meddling manager away from the stuff that was important.<p>The territorial dog analogy is perfect. I&#x27;ve seen parks where they put fake fire hydrants and other features in the dog area so they can feel satisfied without leaving their designated area.

Nice story. I&#x27;m disappointed that it didn&#x27;t end with some helpful tactics for ducks you could put in your own projects, though. I also would be interested to hear the real story of what happened to the author to inspire this writeup.

My company just doesn&#x27;t have product or project managers and it&#x27;s wonderful. Fewer meetings, no intermediaries, more agility. It could only work in practice, it could never work in theory.

I&#x27;ve heard of (but never tried) a similar thing done when showing design concepts to a client. Usually several variations are prepared, and if you&#x27;re any good they will all be viable options. When presenting to a client they will normally want to try and critique something regardless of how good the designs actually are.<p>The story goes that you are supposed to make an obvious mistake, like a spelling error, on purpose. This will fulfill the clients&#x27; need to provide a critique and allow good designs to remain an option.

&gt;It&#x27;s almost like they want to be able to point at any given part and say &quot;I&#x27;m the reason that happened&quot;.<p>I suspect this is done by people that feel like they will need to justify their job later. Having something to say when your manager (or others) inevitably ask &quot;So, what exactly is it that you do here?&quot;<p>This seems to be also prevalent in the movie and tv industry. (Though I wouldn&#x27;t COMPLETELY disparage the usefulness of studio&#x2F;executive notes; see: Star Wars)

I used to work with a very wise and experienced designer who referred to this as the &quot;zinc&quot; (after the &quot;sacrificial protection&quot; used on the hulls of ships)

Doesn&#x27;t this become self reinforcing? As long as the developer keeps adding silly things to his work the PM will be forced to ask for them to be removed, thereby reinforcing the developer&#x27;s mindset that the PM always asks for changes. The PM is put in a position where he has to okay something unusual in order to stop the Dev from adding little unusual things.

Sounds like the duck is a fingerprinting honeypot.

I heard a similar story (a joke from the communist era) around 1995 from a Czech colleague. It was about an artist whose works were never censored.<p>When the other artists asked him how he did it, he replied: &quot;I always add a little white dog in my paintings. When the censor asks &#x27;What is this dog?&#x27; I quickly remove it and he&#x27;s satisfied.&quot;

This reminds me of some contracting work I did for a company that billed the Federal government. I was told that the final invoices sent to them had some obvious and intentional accounting errors such that these would be &quot;caught&quot;, thus satisfying whomever was in charge of approving the invoices on the government&#x27;s end.

This is virtually the same as what is more often called &quot;bikeshedding&quot;, though with a different (just as famous) story: <a href="https://en.wikipedia.org/wiki/Parkinson%27s_law_of_triviality" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Parkinson%27s_law_of_trivialit...</a>

Reminds me a little of the Declaration of Independence where the famous line would have been &quot;We hold these truths to be sacred and undeniable&quot; if Thomas Jefferson hadn&#x27;t been &quot;touched&quot; by Benjamin Franklin with his edit to &quot;self-evident&quot;.

Another version of this story that I love uses the Russian Navy:<p><a href="http://blogs.msdn.com/b/brada/archive/2005/05/12/417064.aspx" rel="nofollow">http:&#x2F;&#x2F;blogs.msdn.com&#x2F;b&#x2F;brada&#x2F;archive&#x2F;2005&#x2F;05&#x2F;12&#x2F;417064.aspx</a>

I&#x27;m sure I&#x27;ve been on the receiving end of this from the guy who does my graphics work. I mostly find it amusing but a it is bit annoying when there is a deadline. I won&#x27;t let on that I know though.

It is called bikeshedding. People have been using &quot;bike sheds&quot; in software development for years to get project managers off their back about the important stuff.

&quot;What is the difference&quot; I could go on for days about the differences between dogs and humans, if only the author had permitted comments to be left on the page.

I&#x27;ve always thought the &quot;just remove the duck&quot; story was a condemnation of the artist, not the manager.<p>If your work is so crappy that you know you have to add something even crappier to distract the reviewer, what does that say about your competence? Maybe I&#x27;m just jaded from years of reviewing awful code. But if someone put an obvious compiler error into their code in hopes that it would distract me and keep me from seeing their memory leaks, off-by-one errors, and mis-spelled variable names, I&#x27;d be wondering if they&#x27;re qualified to be on the project.

More amusing than the article itself are several stories recounted here.

“Too many notes.&quot;

Wonderful game, I played it on Amiga. Beautiful post.

I just want to point out that yes, the rook eats the queen, but at some point, some piece has its manhood removed in a most grisly fashion. Surprised the PM didn&#x27;t have any feedback on that bit.

I wonder how much refactoring is done in this vein!

Great story. even better game...i miss it :(

Humans or animals, it&#x27;s natural to want to leave a mark. The article is pointless.

In the SCRUM shop I used to work, I did this all the time for our QA dept when the sprint was fairly trivial. If I didn&#x27;t the PMs and the BAs would start breathing down their necks like they weren&#x27;t working.

This is the origin story of Richard Stabone (RIP) also. Originally named to be used as a sacrificial bargaining chip with the standards board, he was somehow never cut, leaving Kirk Cameron stuck with a Boner for four years.

Commonly known as a &#x27;red herring&#x27;.