If you keep up with the jargon within the web development and design industry it’s likely that at some point you will have come across the term “duck” at least once or twice. Apart from it being fun to feed bread to them, ducks in the web industry hold at least two completely different meanings.
One of them is referred to as rubber duck debugging, which is when you to talk to a rubber duck toy to explain your problem. In doing so, you’ll figure out the solution without having to interrupt anyone else. Handy, right? It a technique that does work but you must have co-workers who understand what you’re doing talking to a toy.
With joking aside, it does introduce a few techniques into debugging code. By explaining it thoroughly, first, it ensures you have an understanding of the current problem. Secondly, it makes you break down the problem into chunks so you can analyze it properly. Additionally, it’ll strengthen your communication skills to a point where you can confidently describe an issue or reproduction steps, should you then have to do it with real humans.
The other meaning refers to planting a duck in design or code. Only web designers and developers can come up with these sorts of things, I swear. For some context, Jeff Atwood posted an article about internet jargon that included some backstory about the phrase explaining a designer and overzealous project manager which, to quote:
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.”
The idea behind planting a duck is great, especially if you know someone is going to want to leave their mark on a project by changing at least one thing. This would allow you to create a project to match a brief and implement a failsafe that distracts away from the core product you have at the end. It’s also a very tricky move. Due to the nature of the tactic, it is somewhat likely the duck will be missed and actually remain in the product until you take it out which is the complete opposite idea. You’ll want to make sure it’s found.
It’s also impossible to search for duck inspiration online to see what you can do to implement this on what you’re currently working on. The idea being that all ducks have ceased to exist past the launch of anything so examples are out of the question and those ducks that did survive past that, well they’ll be hidden in plain sight and it won’t exactly be easy to spot them.
This does beg the question though, should you be doing something different if you’re needing to resort to design techniques such as this?
Planting ducks can be applied to development practices too, although it could be done in a much more different way such as calling an API that isn’t used anywhere or creating a function that outputs the data it’s given without altering it in any way. It’s easy enough to see something like a duck on a logo for example, but unless you’re using ASCII art in your core files, it’ll be hard to put a duck in your code.
Have you had any experience with the duck tactic?
Personally, I haven’t placed anything you could class as a duck into anything, however I have included the odd ‘Easter Egg‘ here and there like a fun error 404 page for anyone sees it as well the addition of a keyword to the end of a URL that may change the page layout or design slightly. Fundamentally, adding ducks into a product isn’t necessarily a bad thing as long as it doesn’t distract or take away from the original purpose of what you’re making, and that they’re found and removed. It’d be great if we didn’t need to use this kind of technique, but that’s in an ideal world. Until then we’ll just settle with the ducks.
Ultimately, if you have to resort to “planting a duck” in your projects, maybe you need to revisit your workflows and see what you can do to ensure that anyone overseeing or testing a project doesn’t try to alter something away from a brief or specification. I like to think the idea behind it is a stroke of genius but then it does make you realize that sometimes we need to fight back against overzealous project managers in very creative ways.