ATWOOD'S DUCK

Antoine de Saint-Exupéry famously said that perfection was achieved, not when there was nothing more to add, but when there was nothing left to take away.

What if you may have put in hard work and a lot of effort but the manager or client is not satisfied? Then you might benefit from deploying Atwood’s Duck. It’s a cunning manoeuvre to save your work from unwarranted criticism.

In the context of software programming, a duck is an element added to a product design for the sole purpose of drawing attention and directing scrutiny away from other elements – specifically to appease meddling managers.

Originally a programming term, the concept was popularised by Jeff Atwood, co-founder of Stack Overflow. He relates the following anecdote about a computer game design company:

It was well known that producers (a game industry position) 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.”

Atwood’s Duck is synonymous with an attempt to outsmart a manager, client, or stakeholder. But also of organisational dysfunction at the personal level. If you want to keep people from interfering with your work of perfection, give them something too obvious to not criticise, but not so obvious and out there that you look stupid.

It is comparable to Parkinson’s Law of Trivialities, illustrated by the Bikeshed story (previously in Bytes).

In meetings, we tend to spend more time talking about trivial issues (e.g. a company bike shed) than discussing complex and more significant ones (e.g. a nuclear power reactor project). Everyone leaves the complex matters to those they imagine have more knowledge and understanding, dealing with the less complex, which they understand, with more time and debate. As a result, decisions are made at the lowest level of everyone’s expertise.