Some of the popular anecdotes in software development circles have very little to do with software; they’re about people, and are broadly applicable. I want to highlight two of them here, to make them easier for me to share with others, without having to cite specific paragraphs in people’s blog posts, and hopefully elevate them to a wider audience. As fate would have it, both involve ducks, and both have been surfaced by Jeff Atwood in his blog at various points. While they have become somewhat common programmer jargon, they could just as easily be general management slang as well.
In a blog post by StackOverflow co-founder Jeff Atwood the general concept is discussed, but the origin storyNote* is also linked to and partially quoted. Here it is in full, in case the source ever disappears:
When I was a younger person, my first full-time adult-type job was designing automatic fire sprinkler systems. It was an eye-opening and educational experience, and even though the job basically sucked, I learned all kinds of crazy stuff in that job that I use daily in my present-day non-sucky job, so I can’t complain.
One interesting lesson was learned at the hand of the Chief Superintendant, Bob. Bob was in charge of installing the systems that me and my group designed. People who put things in, I quickly learned, have a wealth of knowledge and experience about things that people who only design never gain. As a result, when I first started in that job, I wound up going and bugging Bob for answers on a regular basis.
This annoyed Bob. Bob liked to sit in his office and shoot the shit with his buddies on the topics of fishing or hunting. He did not like fielding questions from young designers. This was especially true because, in his opinion, many of the questions could be answered by me, without bothering him, if I would just think about it the right way. At one point he got fed up. When I came into his office and opened my mouth to start asking whatever question I had, he told me to stop.
Bob pointed into a corner of the office. “Over there,” he said, “is a stuffed duck. I want you to ask that duck your question.”
I looked at the duck. It was, in fact, stuffed, and very dead. Even if it had not been dead, it probably would not have been a good source of design information. I looked at Bob. Bob was dead serious. He was also my superior, and I wanted to keep my job.
I awkwardly went to stand next to the duck and bent my head, as if in prayer, to commune with this duck. “What,” Bob demanded, “are you doing?”
“I’m asking my question of the duck,” I said.
One of Bob’s superintendants was in his office. He was grinning like a bastard around his toothpick. “Andy,” Bob said, “I don’t want you to pray to the duck. I want you to ASK THE DUCK YOUR QUESTION.”
I licked my lips. “Out loud?” I said.
“Out loud,” Bob said firmly.
I cleared my throat. “Duck,” I began.
“Its name is Bob Junior,” Bob’s superintendant supplied. I shot him a dirty look.
“Duck,” I continued, “I want to know, when you use a strap hanger, what keeps the sprinkler pipe from jumping out of the strap when the head discharges, causing the pipe to…”
In the middle of asking the duck my question, the answer hit me. The strap hanger is suspended from the structure above by a length of all-thread rod. If the pipe-fitter cuts the all-thread rod such that it butts up against the top of the pipe, it essentially will hold the pipe in the hanger and keep it from bucking.
I turned to look at Bob. Bob was nodding. “You know, don’t you,” he said.
“You run the all-thread rod to the top of the pipe,” I said.
“That’s right,” said Bob. “Next time you have a question, I want you to come in here and ask the duck, not me. Ask it out loud. If you still don’t know the answer, then you can ask me.”
“Okay,” I said, and got back to work.
In the months that followed, I had many questions. I followed Bob’s directions and asked the duck my questions. I believe that 50% of the time, asking the duck produced the answer.
Why does this work? I am not sure. I think there is something about framing your question as a verbal inquiry that causes your brain to work on it differently. You turn the question around and see it from another angle – the angle of the person answering the question. This, in turn, causes your own brain to put itself in the answerer’s shoes – and, because we are basically clever apes, we have the tools to come up with smart ideas all on our own.
Fast forward to my current job. I am no longer a young designer. I am now an officer in a medium-size engineering firm. I do less designing than managing these days. And I get asked a lot of questions.
A few months back, after being interrupted for the sixth time that day by a very smart young engineer who had a question for me, I chose not to answer. Instead, I took the young man down the hall from my office and into a huddle room. Hanging in the huddle room was a photograph of our company’s founder shaking hands with a politician.
“This,” I said, “is Newt Gingrich, 58th Speaker of the US House of Representatives, and he is generally considered a smart fellow, even by those who despise him.” My young engineer looked up at Newt, wondering where on Earth this could possibly be going, just as I had done with Bob and the duck many years ago.
I get less questions these days. But I think my young engineers get better answers, because there is no thinking quite so well-understood as thinking you do for yourself, even if you get a little help from a duck, or a politician, even one I loathe.
What I like most about this story is that it has nothing to do with software. It is also not using a rubber duck, it’s very much a real, once-was-alive duck, now in taxidermy form. And it’s a rather good story.
Rubber ducks are more popularly associated with this idea. Of course, if one can put themselves in the mindset of explaining the problem to an outsider, a physical object is unnecessary. This has numerous other benefits, like improved writing because one knows the audience will not be as familiar with the subject as the author.
Note: This is unlikely to be the origin of the term. The LiveJournal post is dated 2012, and the commonly cited origin is “The Pragmatic Programmer”, circa 1999, which has a section titled ‘Rubber Ducking’, and cites the firsthand experience of one of the authors interacting with a developer who carried a yellow rubber duck, but there is not much story presented beyond that. Both sources cite experiences that happened some unspecified time in the past: I think the LiveJournal story is more compelling as an origin, by rule of cool.
What was originally a StackOverflow answer by kyoryu to a question about new jargon which was subsequently deleted for being off-topic, was then preserved by StackOverflow co-founder Jeff Atwood on his blog for even greater exposure:
A Duck: A feature added for no other reason than to draw management attention and be removed, thus avoiding unnecessary changes in other aspects of the product.
I don’t know if I actually invented this term or not, but I am certainly not the originator of the story that spawned it.
This started as a piece of Interplay corporate lore. It was well known that producers (a game industry position, roughly equivalent to PMs) had to make a change to everything that was done. The assumption was that subconsciously they felt that if they didn’t, they weren’t adding value.
The artist working on the queen animations for Battle Chess was aware of this tendency, and came up with an innovative solution. He did the animations for the queen the way that he felt would be best, with one addition: he gave the queen a pet duck. He animated this duck through all of the queen’s animations, had it flapping around the corners. He also took great care to make sure that it never overlapped the “actual” animation.
Eventually, it came time for the producer to review the animation set for the queen. The producer sat down and watched all of the animations. When they were done, he turned to the artist and said, “that looks great. Just one thing - get rid of the duck.”
This has little to do with software, and everything to do with managing faux-collaborators. Outside of software, this can easily apply in any kind of design-by-committee exercise. If you’re bringing a proposal, and your collaborators have shown a propensity for nonsense suggestions for the sake of participation, give them something to draw their focus.
In software, this is the sort of covert upward management few would admit to. But among colleagues, this may get some playful usage implying someone is a duck practitioner:
and in the corollary form, ‘put a duck on it’:
Actual ducking is not without risk. If no one is actually paying attention or feeling like meddling, your ducks may start shipping and become a theme in the product.
2025 Greg Chabala