Developing a feature which sole purpose to be taken out?

Question

What is the name of the pattern in which individual contributors (programmers/designers) developed an artifact for the sole purpose is to serve as a diversion so that management can remove that feature in the final product?

This is a folklore I heard from an ex-colleague who used to work at a large game development company. At that company, it is well known that middle management is pressurized to "give inputs" and "make changes" to the product otherwise they risk being seen as not contributing to the project. This situation have delayed many projects because of these superfluous "management inputs".

In one project at the above company, the artists and developers created a supernumerary animated character that appears in every cutscene and sticks out like a sore thumb. They designed it in such a way that it can be easily removed before the game is shipped (this was when games were still sold in physical media and not a downloadable product). Obviously the management then voted to remove the animation. On the positive side, management didn't introduced any unnecessary changes that would have delayed the project because they have shown that they provided constructive inputs to the product.

This process pattern has a name among game programmers that work in corporates, but I forgot what was the actual name. I believe it's duck-something. Anybody can help pointing out the name and perhaps some rather credible reference to how the pattern develops?.

Answer 1

It’s called a duck, from a legend that allegedly comes from Interplay’s Battle Chess:

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

Answer 2

I simply see it as management validating their own purpose on a project by extending out scheduled work as long as possible or creating meaningless busy work to keep people busy or working.

I have seen this personally in five different types:

• Government projects - Many times if a manager's project runs underbudget or time, then it will work out bad for him/her in the future. They may get praise for good work, but run the risk in the future that their budget will be reduced next year if they can't justify it. Because of how budgeting works in government, this is why government projects aim to utilize as much of their assigned budget as possible.

• A possibly obsolete manager who has a large team and responsibility for software that is relatively easy to maintain or write. The danger is real in the corporate world that when they try to shed dead weight they will look for the middle managers with the least real responsibility and move from there. They feel that by overestimating and creating unnecessary scope that they protect their positions.

• Some software companies are basically Good Ol' Boy clubs where they have simple or legacy software that corners a lucrative yet niche market. Typically the money is relatively easy, ambitions relatively low, and all of the managers are best friends who try to validate each others purpose while taking home big paychecks. Room for advancement is impossible in such companies unless you are connected. They will often try to validate their own importance by creating meaningless busy work into an already well solved problem.

• Some contract language requires regular releases and continuous improvement in the software. For a well solved problem, finding unique and new features may be difficult or impossible. Often busy work will be assigned, perhaps maybe to add something then mostly remove it in the next release.

• The manager is legitimately concerned with keeping the team together, either out of guilt or just trying to be nice. He will try to validate the purpose of his own team to keep them employed under him.

Answer 3

My boss called it the "fountain strategy". He designed a new computer wing for a University with a massive fountain out the front. The wing was approved but without the fountain, exactly as planned.

That was 50 years ago, so this is nothing new.

Answer 4

In some projects I've worked on, we've called them "bike sheds" as a nod to the term bike shed problem. This term came from a passage the book Parkinson's Law, describing nuclear power plants as being so complicated that mismanagers would be afraid to touch anything, but a bike shed is so simple that everyone has to dither and fiddle with it to give the appearance of "managing" things.