
“Just remove the duck” (2013) - tarikozket
https://rachelbythebay.com/w/2013/06/05/duck/
======
mvdwoord
A story from the time recounts that Piero Soderino, the head of the powerful
Florentine Republic, even told the famously irascible Michelangelo that
David'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 "chiseling" 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 "life-like."

[http://www.globusjourneys.com/travel-
stories/italy/michelang...](http://www.globusjourneys.com/travel-
stories/italy/michelangelos-david/)

~~~
TallGuyShort
Not a huge Steve Jobs fan, but I had a professor who had worked as a designer
under Steve Jobs and tried something similar. Steve insisted that a new mouse
needed to be just a fraction of a millimetre slimmer so a person's palm was
lower and closer to the work surface. They figured he was being an
unreasonable "delicate genius" and returned a few days later with the
identical mouse and claimed they had reworked it to be a little slimmer. He
held it and immediately said they had done nothing and the size was identical
to before. They took it and reworked it to actually be about half a millimetre
slimmer, showed it to him, and he said it was perfect.

~~~
sxp
There is a similar story about Larry Page when Gmail was being developed:

    
    
      Before Google launched Gmail in 2004, its creator, Paul Buchheit, brought it to 
      Page’s open cubicle office for a review.
    
      As Buchheit called the program up on Page’s computer, the boss made a face.
    
      “It’s too slow,” Page said.
    
      Buchheit disagreed. It was loading just fine, he said. No, Page insisted. 
      It had taken a full 600 milliseconds for the page to load.
    
      “You can’t know that,” Buchheit said. But when he got back to his office, 
      he looked up the server logs. It had taken exactly 600 milliseconds
      for Gmail to load.
    

[http://www.businessinsider.com/larry-page-the-untold-
story-2...](http://www.businessinsider.com/larry-page-the-untold-
story-2014-4#ixzz3TLJzGy9x)

It is quite plausible for people who being to obsess over a certain aspect to
become overly sensitive to it. In my case, a lifetime of playing high speed
video games makes it possible to notice things that others miss when it comes
to things like framerates and microstutter in computer graphics. I find it
likely that Jobs and Page were able to pick up on millimeter & millisecond
defects.

~~~
sytse
Great story, I hope that Larry loads drive.google.com sometime this week and
orders that the loading time has to improve as well

~~~
NegativeK
I thought you were being hyperbolic, but Drive really does take second god
damn seconds to load.

~~~
sytse
Indeed, it takes multiple seconds, I have a drive tab pinned permanently to
avoid it (actually two tabs, one for each google account I use)

------
sstradling
I'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 "that's stupid". Adding the duck binds your co-workers and
successors to a life of misery.

There's a real risk (of course) to killing the duck. Your client or your boss
may hate you, and that'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.

Kill the duck.

~~~
lmkg
There's merit to this position. You can think of this as the
process/organization equivalent to technical debt. Every problem that you
introduce a hacky work-around, that root problem sticks around and keeps
generating more and more hacks and work-arounds. The end result is incompetent
management.

That doesn't mean it's _always_ the wrong decision, though. Sometimes,
technical debt is the right trade-off. Sometimes the trade-off of teaching
your boss just isn't worth the effort, and getting the job done quickly works
out.

And, just like technical debt, doing this results is more problems for other
people (including future-you) as your bad boss looks good and calcifies his
bad habits and rises in the ranks.

Personally, my preferred solution is malicious compliance. If someone makes a
stupid decision, they have them suffer the consequences of that stupidity
rather than covering for them and letting them delude themselves that their
bad decision was good. This only works on new decisions, though; if you try to
remove existing work-arounds for old bad decisions, you're the one that looks
bad.

~~~
arjunrc
This is how corporate life works & it took five years for me to come to terms
with it. However, I have done much better as an Employee (in the eyes of my
Manager/Company) ever since.

Once you develop a good reputation by playing the game, you can always fix old
bad decisions & at that point, your superiors would actually encourage you to
do so.

------
flarg
I hate this story.

I think it'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's also rather disrespectful to 'cheat' and make
fake changes just to make the someone happy. No-one deserves to be treated
like a 'mark' for our tricks.

My experience has been that being honest, polite and knowledgeable is a much
better approach.

~~~
fallinghawks
I would guess you've never browsed through clientsfromhell.net.

Being honest, polite, and knowledgeable doesn't change the fact that the
person who hires you may be ignorant, too busy, dead set on cheating you, or
needs to assert his/her sense of control by insisting on changing _something_
you considered finished.

~~~
SonicSoul
that may be so, but tricking them into making the right decision is not a good
long term decision. If they can't respond to reason perhaps changing teams and
companies is a better approach.

~~~
NegativeK
"Quit your job" is not a reasonable solution to intractable problems. The duck
isn't either, but the change jobs mentality is even more damaging than a duck.

------
Flemlord
Putting on my client/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.

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.

~~~
Nacraile
I think you're missing the point. The point here is that some PMs feel that if
they're not demanding changes, they are not necessary / not doing their job /
etc. If there's nothing wrong with the completed work, such a PM will demand
unnecessary changes, in order to justify themselves.

The duck is a passive counter to the PM's pathological behaviour: ensure
there's always some easily-fixed fault, so the PM can feel like they're doing
something, without forcing unnecessary high-effort changes. Since the duck is
obviously bad and easily removed, it shouldn't prevent the PM from noticing
real issues, or detract from fixing real issues.

If you feel the need to add ducks, the real problem is that you have a bad PM.
But if you're a dev and have no good way to solve the real problem...

~~~
Elepsis
The problem is that it's not uncommon for a dev/designer/etc. to not
understand some of the reasoning for why a PM is requesting changes be made.
We all snicker at the incompetent PM who just wants to "make their mark" on a
project, but very often the demand that may appear that way is motivated by
entirely legitimate concerns. (And yes, the PM should bring the dev along with
them, etc.) If you "add a duck" and the PM ends up missing the legitimate
concerns as a result, everyone loses.

The add-a-duck attitude fundamentally assumes that the dev/designer knows
what's best for the end product and the customer, and while that happens some
of the time, the reason the PM role exists in the first place is because
that's not always true. :)

------
krylon
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. "I'll see what I can do", the guy
would sigh, go to his office, remove the offending code, and voila - everyone
was happy.

I haven't had the opportunity to try this technique, but I have been waiting
ever since for the moment where this might come in handy.

------
LanceH
This is classic military when presenting anything to an officer for review.
I'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's a way of life on the military, really.

~~~
Disruptive_Dave
Client services, as well. I was Director of a partnership marketing agency
that had blue chip clients (IBM, FedEx, etc.). Any time we presented
concepts/ideas to our clients we ALWAYS 1) included a few "easy no's" and 2)
held back one or two good ones (most times). I have a quote hanging on my wall
that reads: "Ideas are 1%, execution is 49%, getting people to own the idea is
25%, making those people heroes is 25%" (Chris Brogan). I think that's a
positive way to spin this situation.

------
wambotron
I worked at a deli during college, and people did this same type of thing on
slices. By default, I'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 "thinner," I would pretend to fiddle with the knob, slice the same
thickness, and they'd say "perfect!"

I think it gives them some sort of feeling of control and ownership over what
is happening.

~~~
chestervonwinch
or maybe they don't want to appear rude or finnicky by pointing out that it
looks the same?

~~~
MarkyC4
This was my thought too. I've already asked you to "fix it for me" once. I
feel to do so again would just be rude (and wasteful as now 2 slices would
have to be put aside for another person, or thrown out)

~~~
swagasaurus-rex
By extension, asking for a change in itself is presumptuous, so coming back
with the same product is returning the favor.

------
jauco
Funny how she mentions dogs.

In Dutch it is a common expression to say something like "And then of course
he has to pee on it a bit". (Hij moet daar nog even een plasje over doen) to
indicate exactly this behaviour.

~~~
Yhippa
Ha, I thought this was some abstract joke my friends and I make when we see
this type of behavior. Funny that it's apparently universal.

------
robmcm
Dilbert has this covered:
[http://dilbert.com/strip/2007-02-02](http://dilbert.com/strip/2007-02-02)

~~~
lotharbot
An older Dilbert on the same theme:
[http://dilbert.com/strip/1997-07-12](http://dilbert.com/strip/1997-07-12)

~~~
polym
younger _

~~~
lotharbot
something from 18 years ago is older than something from 8 years ago.

~~~
hobarrera
Dilbert (the character) was younger 18 years ago comparted to 8 years ago.

------
emodendroket
I guess this is probably the story she's referring to:
[http://blog.codinghorror.com/new-programming-
jargon/](http://blog.codinghorror.com/new-programming-jargon/)

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

~~~
bmh100
The "helicopter" may also be related to the "anchoring effect" [1], where
adding such an expensive item with inflate the final cost of the project. That
final cost will be the starting point, or "anchor", for clients to evaluate
the true value and appropriate price of the project.

[1]:
[https://en.wikipedia.org/wiki/Anchoring](https://en.wikipedia.org/wiki/Anchoring)

~~~
smcl
This hooks nicely back into the world of software development, and the
anecdote about the senior game dev deleting a secret static 1MB buffer when
their team hit their memory ceiling -
[http://www.dodgycoder.net/2012/02/coding-tricks-of-game-
deve...](http://www.dodgycoder.net/2012/02/coding-tricks-of-game-
developers.html)

------
wilwade
NPR had a story about this in graphic design where it has the term "Hairy
Arms": [http://www.npr.org/2014/11/17/364760847/whats-with-all-of-
th...](http://www.npr.org/2014/11/17/364760847/whats-with-all-of-the-hairy-
arms-in-graphic-design)

~~~
hoopism
I've heard about this before. The person who was telling me about it said that
in almost all cases the C-level person they were dealing with would choose the
"hairy arm". Had an unintended way of backfiring frequently.

~~~
wlesieutre
The "hairy arm" in this case isn't an alternate version, it's an obvious error
added to the design so that the manager can tell you to remove it.

Though I've definitely also heard of people making a deliberately terrible
alternate design and having a client pick it.

~~~
hoopism
Yes. That is where the term comes from... but it encompasses the practice of
using an intentionally "wrong" option.

From the linked article:

"FREASE: Exactly. And it's funny I'm saying this but yeah. You know, it
happens. Everybody does it. Like, for example, I worked with - 10 years ago -
I worked - we did these logos for a famous musician. And they had a lot of
people working for them and a lot of voices. And after working with them for a
couple weeks, we realized that they hated the color blue. So if we showed them
three logos, we would show the ones we loved. And then, we'd do one that they
wanted, but we'd put it in the color blue."

------
kyberias
There's a certain tone in this article that bothers me a bit.

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's not
about being fair, it's not personal, and it probably isn't even dependent on
the reviewers personality. It's just that when the goal is to find deviations,
that's what happens. It's just a process. The errors may be small or big, it
doesn't matter, we just need to find them.

Some inexperienced developers often find the code review process intimidating
and unfair. They take it personally. That's a wrong attitude.

~~~
kevinskii
About a year ago I had the misfortune of working with a program manager. He
asked me to create a PowerPoint presentation on something totally unimportant
and irrelevant. After failing to explain this to him, I decided to accommodate
him figuring that he would become more reasonable once he knew a bit more.

After emailing him the presentation, he called and asked me to switch the 2nd
and 3rd bullet on one of the slides and then send him the revision. Our
relationship went downhill from there. Finally I had no choice but to
marginalize him.

I don't think the author of the article had code reviews in mind; she's
alluding to this sort of nonsense when you sense her negative tone.

~~~
kyberias
You're probably right she didn't have code reviews in mind. Perhaps I was just
worried that someone takes this as an example and will do some crazy
unnecessary tricks in software.

Also, I don't have any experience of such absurd situations despite my
experience working with dozens of teams. Maybe that's because I'm from
Northern Europe where professionals don't take such bullshit from anyone.
Oops... perhaps slightly strong wording. Well, I guess you get the point.

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

~~~
jsight
[https://www.youtube.com/watch?v=QM3InfEH-
cU](https://www.youtube.com/watch?v=QM3InfEH-cU)

~~~
moron4hire
>> "From the PC game Battle Chess (Enhanced) by Interplay. The reason I
discovered I was into vore."

I really, really shouldn't read even the _descriptions_ on YouTube videos.

~~~
cmstoken
I would also advice not going to the user's Google+ account. I was curious,
and I regret it.

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

~~~
vidarh
Agreed. Our son always "decides" what he's having for dinner and what to do
during the weekends, for example.

Only he decides by choosing between 2-3 options we've selected in advance to
match what we want the outcome to be.

Similarly it's always bedtime before his actual intended bedtime so he can
negotiate some extra time. It avoids so many conflicts when he smugly believes
he has gotten exactly what he wanted out of us.

I think works on pretty much anyone, you can just be more blatant about it
with some people than others.

~~~
mod
I like giving him different veggie options for the illusion of choice.

I don't like letting him "get one over" on bedtime. When he's old enough to
know the difference, then what? You'll have to take away those wins. Same goes
for basically everything else he'll want from you.

At least he'll (hopefully) negotiate well!

~~~
vidarh
I figure when he's starting to realise that the wins are not really wins, he
will also realise he's not been "getting one over" on us.

At the same time, there are always things you can negotiate on. E.g. I don't
care if he's up until 10pm if he can prove to me that he will consistently get
up on time and do well at school despite staying up late.

We're already playing that with him: We point out in the mornings if we notice
he's tired that he seemed to have gone to bed too late, and we "trade" going
to bed earlier on school nights against staying up later during the weekend.
As a result he sometimes tells us he wants to go to be before the agreed
bedtime.

And I'm willing to be flexible about all kinds of things as long as he's
giving us something reasonable in return. E.g. he gets weekly home work, and
so I'm willing to skip on doing it one evening if I can trust that he will
stick to an agreement of more than making up for it the following evening (and
if he doesn't, he knows the consequence is much less freedom for a long time).

I've no doubt I'll still have plenty of challenges down the road.... And he is
already a master negotiator, though sometimes he's trying to be too wily for
his own good and sometimes ends up talking himself out of a good deal because
he doesn't yet understand all the options well enough. So he gets maths
lessons this way too...

------
myth_buster
I'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'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?

------
stevewilhelm
I have routinely left known performance optimization tasks to be done after
the initial review of a product'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.

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' feeling of ownership of the product and they were more
likely to become product champions and evangelists.

------
bitL
You'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'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'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...

------
moron4hire
I'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's no trouble to remove it.

I'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'm a "genius" when I can make these "big"
changes in such short periods of time.

Hell, I even tell them I'm going to do it. I'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.

~~~
realrocker
I think most freelancers do this. I have done it my time.

------
agumonkey
Similarly, always give options, subtly worse than the one you want to see
picked. See Dan Ariely's books.

~~~
icebraining

      Bernard Woolley:      What if he demands options?
    
      Sir Humphrey Appleby: Well, it's obvious, Bernard. The Foreign Office will
                            happily present him with three options, two of which
                            are, on close inspection, exactly the same.
    
      Sir Richard Wharton:  Plus a third which is totally unacceptable.
    
      Sir Humphrey Appleby: Like bombing Warsaw or invading France.
    

_Yes, Minister - A Victory For Democracy_

~~~
dasboth
Wish I could upvote this twice, "Yes, Minister" is full of stuff like this.

------
chrisbennet
An electrical engineer I worked with told me about a similar situation he had
encountered at a previous job.

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.

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.

------
blawson
I think a lot if this effect is just that people think differently from each
other.

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.

If you'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.

------
samf
I have thought about the same tactic if you are selling your house, and the
potential buyer is bringing an inspector.

"Break" 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.

If you don't do this, the inspector will find three other things.

Of course this would only work if your house doesn't need any significant work
done in the first place.

~~~
omegaham
Just to provide a counterpoint, I had a master sergeant who would flip the
fuck out if he saw obvious problems. The idea was that if he could find
obvious problems, then his juniors don't give a fuck at all, and there are
going to be a lot more not-so-obvious problems. This was a cue for him to go
on a rampage through the section and cause pain and hardship for everyone.

------
loudmax
We, as engineers, should also resist the temptation to leave our own mark when
we're reviewing products designed by others. I don't work in management, but
I'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's own suggestion implemented. The temptation
to leave one's mark just for its own sake is something we should all be aware
of.

------
asgard1024
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.

------
dctoedt
For lawyers drafting contracts, there's a quite-legitimate, signaling-related
reason for "doing the duck." By giving the other side's contract reviewer
something to object to and revise, _it lets her demonstrate to her boss that
she did her job competently._ For example, she can then report to her boss (or
client), "they wanted net 15 days payment terms but I made them change it to
net 30; otherwise it was an OK contract." That in turn can help get the
contract out of legal review, and into the signature process, more quickly.

This is sort of related to the story about Van Halen's concert contract that
required a bowl of M&Ms in the dressing room with all brown M&Ms removed. [1]

[1]
[http://www.snopes.com/music/artists/vanhalen.asp](http://www.snopes.com/music/artists/vanhalen.asp)

------
Gravityloss
How much of our work in this business is just useless theater?

I couldn't stand working in a place where it was a significant portion of
work. But it is probably unavoidable to some degree.

I see that code reviews for newcomers' commits often have these elements:

First review: "you did X. That's not smart. Do Y instead."

The new employee goes back to rework their commit.

Second review: "you did Y. That's not smart. Do X instead."

After a few weeks / months it starts getting reasonable. It's not as extreme,
and it's well disguised in friendly demeanor, but there's still some
similarities to what it was like in the army "boot camp".

------
doki_pen
It's not about leaving your mark, it'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.

------
larrys
It'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 "money hasn't been left on the table" 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.

------
jaydles
[Here's the link to the Stack Exchange
post]([http://programmers.stackexchange.com/questions/122009/develo...](http://programmers.stackexchange.com/questions/122009/developing-
a-feature-which-sole-purpose-to-be-taken-out)) (on the Programmers site)
that's reverenced in the blog post.

------
cmpb
This reminds me of "How a Web Design Goes Straight to Hell" [1] by The
Oatmeal. It's a different moral, of course; basically, don't trust the client
more than you need to.

[1]
[http://theoatmeal.com/comics/design_hell](http://theoatmeal.com/comics/design_hell)

------
TallGuyShort
>> The sacrificial duck kept the meddling manager away from the stuff that was
important.

The territorial dog analogy is perfect. I'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.

~~~
agumonkey
I'd love a exhaustive course on this kind of fakery.

~~~
ars
How about buttons by crosswalks that don't do anything?

~~~
agumonkey
Can't say, my driving instructor told me to pay attention to people near them
because it does affect traffic lights (and even sequences of them). Other than
that, it's pretty possible it's just a decoy to trigger pedestrians patience
because they think lights are about to switch.

------
amikula
Nice story. I'm disappointed that it didn'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.

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

~~~
bgroins
As someone who is responsible for 10-15 concurrent IT projects across numerous
teams, many of whom I don't manage, this sounds terrible. I think the "no PMO'
approach may work for homogenous groups whose focus is one project, but for a
large organization, effective project management is a must.

~~~
tfederman
That's maybe true, and also a good reason I wouldn't work for a large company
again.

------
chrismbarr
I'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'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.

The story goes that you are supposed to make an obvious mistake, like a
spelling error, on purpose. This will fulfill the clients' need to provide a
critique and allow good designs to remain an option.

~~~
smacktoward
The variation on this that I'm familiar with relies on our perception of three
as a magic number for choices: two options doesn't feel like a real choice,
four feels like _too many_ choices, but three is perfect. So when you're
presenting design concepts, you show three: the one you want the client to
pick, another that's very similar to the one you want the client to pick but
with some obvious glitch in it, and a third that's so atrociously ugly nobody
would choose it. The client goes for the one you want them to go for every
time.

~~~
swagasaurus-rex
Ah, the apple pricing model

------
KoulMomo
>It's almost like they want to be able to point at any given part and say "I'm
the reason that happened".

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 "So, what exactly is it that you do here?"

This seems to be also prevalent in the movie and tv industry. (Though I
wouldn't COMPLETELY disparage the usefulness of studio/executive notes; see:
Star Wars)

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

------
amckenna
Doesn'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'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.

------
pithon
Sounds like the duck is a fingerprinting honeypot.

------
hok
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.

When the other artists asked him how he did it, he replied: "I always add a
little white dog in my paintings. When the censor asks 'What is this dog?' I
quickly remove it and he's satisfied."

------
mendelk
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 "caught",
thus satisfying whomever was in charge of approving the invoices on the
government's end.

------
vezzy-fnord
This is virtually the same as what is more often called "bikeshedding", though
with a different (just as famous) story:
[https://en.wikipedia.org/wiki/Parkinson%27s_law_of_trivialit...](https://en.wikipedia.org/wiki/Parkinson%27s_law_of_triviality)

~~~
mdekkers
no, it isn't bikeshedding at all.

~~~
gknoy
It's related, though -- it's a process you can do to help minimize the impact
of bikeshedding by baiting it with something innocuous.

E.g., you design your awesome nuclear power plant, and put a REALLY ugly
bikeshed, so that the reviewers will feel compelled to expend their change-
requesting energy on that, rather than on changing something that might affect
the important stuff.

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

------
mcfunley
Another version of this story that I love uses the Russian Navy:

[http://blogs.msdn.com/b/brada/archive/2005/05/12/417064.aspx](http://blogs.msdn.com/b/brada/archive/2005/05/12/417064.aspx)

------
tonyedgecombe
I'm sure I'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't let on that I know though.

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

~~~
mattmanser
No, bikeshedding is something completely different.

[http://en.wikipedia.org/wiki/Parkinson%27s_law_of_triviality](http://en.wikipedia.org/wiki/Parkinson%27s_law_of_triviality)

This is about how some managers feel they have to suggest a change, any
change, to justify their position.

Bike shedding is excessive discussion in committees/group emails about trivial
matters because everyone feels they understand the issue, unlike more complex
issues up for discussion.

~~~
korethr
Correct, but a similar cause underlies both. From PHK's email on bikes-heds,
"somebody will seize the chance to show that he is doing his job, that he is
paying attention, that he is _here_."

The project manager needs to show that's he's here and actually doing things,
and so decrees changes like getting rid of the duck or changing the color of
the buttons from taupe to mauve. In bikeshedding, all the people commenting
need to prove that they're there and contributing, so now everyone is
suggesting color changes. It seems to me that the main difference is the
number of people involved.

~~~
mattdlondon
Yep - you offer up a sacrificial bikeshed/duck for management to meddle with,
whilst the important stuff is left alone. Could be one person or a
committee/group - its the same thing.

~~~
mc32
Or, as Thomas Jefferson did, you overwhelm them with excessive preparation, so
that they are reduced to making minor suggestions and your vision goes
through.

[http://www.johndcook.com/blog/2011/03/03/thomas-jefferson-
me...](http://www.johndcook.com/blog/2011/03/03/thomas-jefferson-meetings/)

------
TylerH
"What is the difference" 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.

------
ryandrake
I've always thought the "just remove the duck" story was a condemnation of the
artist, not the manager.

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'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'd be wondering if they're qualified to be on the project.

~~~
myth_buster
I think you missed the spot. "Just remove the duck" is a pattern not an anti-
pattern. What it addresses is the urge of some supervisors to ask for some
change just to show that they have done a thorough review, while the said
change are actually detrimental to the product.

> memory leaks, off-by-one errors, and mis-spelled variable names

The above don't fall into the review comments that are being avoided as these
are valuable suggestions.

~~~
ryandrake
No, I get the _intended_ meaning of the story, putting a decoy in for that
meddlesome boss. But I think it can be interpreted both ways. For every
manager out there who, out of hubris, needs to "leave their mark," you can
find an artist or craftsman who, out of the same hubris, believes their work
is beyond criticism.

~~~
myth_buster
I agree with your above comment while the previous comment was leaning towards
one side.

> story was a condemnation of the artist, not the manager

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

------
picks_at_nits
“Too many notes."

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

------
disillusioned
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't have any feedback on that bit.

~~~
swagasaurus-rex
If this were reddit, somebody would already have the video link handy

------
teddyuk
I wonder how much refactoring is done in this vein!

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

------
enlightenedfool
Humans or animals, it's natural to want to leave a mark. The article is
pointless.

------
brogrammer90
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't the PMs and the BAs would start
breathing down their necks like they weren't working.

------
john_butts
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.

------
johntaitorg
Commonly known as a 'red herring'.

