5 ms·

So my dad told me this story once, He was working on a large, industrial construction project and they were nearing the end of it, so a QA engineer was schedul

So my dad told me this story once, He was working on a large, industrial construction project and they were nearing the end of it, so a QA engineer was scheduled to do a walk-through, and before that happened a higher-up purposefully damaged finished work, dented a pipe with wrench, unscrewed a bolt, etc... That way when the QA engineer did his checks, he'd find these obvious, easily fixable defects and mark them, whereas if he had found no problems, he would end up digging deeper, since he'll feel like he has to find something, and then he might potentially uncover some major, catastrophic problem that'd be impossible to fix and still hit the customer's deadline. Theoretically everyone's happier at the end of it... QA because they did their job and found stuff wrong, the client cause the project was finished on time, and all that for an afternoon of extra work. I worked for a company with an extensive QA process and on occasion I found myself being less then thorough before handing the code off. I knew there were bugs, but just left them in there, because they had bug quotas they had to meet, and we had a tight deadline, etc... At least that's what you tell yourself to justify the behavior. Sometimes I wonder just how much of this kind of greasing-the-wheels goes on in other industries...

sitharus 8y ago
It happens all over the place. I haven't done it to QA but I've certainly done it to project managers, similar to this story: https://rachelbythebay.com/w/2013/06/05/duck/ https://rachelbythebay.com/w/2013/06/05/duck/
scott-smith_us 8y ago
I used to do this defensively when submitting 8-bit games for publication back in the 80s. The non-gamers at the publishing company seemed to feel they had to get back to you with a handful of changes. If your game was really polished, the changes would be pointless or even harmful things. I quickly learned to leave in a few obvious things that were trivial fixes, e.g. blocky bitmaps, misspellings, jarring colors. Instead of coming back with: > we really like the game, but couldn't the snake be an F-15 fighter, and couldn't the scrolling be vertical instead of horizontal? ...it would be more like: > Change that color, fix that icon, correct that spelling
- deleted 8y ago
  [deleted]
- makapuf 8y ago
  See also the story of the duck and the queen on game battle chess https://en.m.wikipedia.org/wiki/Battle_Chess https://en.m.wikipedia.org/wiki/Battle_Chess
  - icc97 8y ago
    The source of that is from a codinghorror post [0] [0]: https://blog.codinghorror.com/new-programming-jargon/ https://blog.codinghorror.com/new-programming-jargon/
  - yebyen 8y ago
    Came here to say this! I've told this parable of the duck before, but I did not know the origin of the story... "get that duck out of there please otherwise looks OK"
- shoo 8y ago
  similarly, in the context of nightmarish optimisation death marches to fit inside a memory budget -- see "the programming anti-hero" https://www.gamasutra.com/view/feature/4111/dirty_coding_tricks.php?print=1 https://www.gamasutra.com/view/feature/4111/dirty_coding_tri...
neumann 8y ago
I did this in our University laboratory for OHS, we called it window shopping. By giving the inspector a few easily visible, but not dangerous issues out in the open, he was satisfied we were up to scratch safety wise but could also tick all his little boxes. An out of date MSDS for chemicals we no longer had, a not tested and tagged electrical cable used prominently, a drink bottle left next to the lab computer by a student.
Graham24 8y ago
I've done this, leave an obvious trivial bug for the QA to find otherwise they'll keep digging until they find something pointless and hard to fix, which is not a problem in the first place. they have to find something to justify their jobs. I wonder if there's a name for doing this?
- bklaasen 8y ago
  That's a team-wide failure to understand business value.
cimmanom 8y ago
This is much scarier for a construction project than the game programming anecdotes that follow.

sitharus 8y ago

It happens all over the place. I haven't done it to QA but I've certainly done it to project managers, similar to this story: https://rachelbythebay.com/w/2013/06/05/duck/ https://rachelbythebay.com/w/2013/06/05/duck/

scott-smith_us 8y ago

I used to do this defensively when submitting 8-bit games for publication back in the 80s. The non-gamers at the publishing company seemed to feel they had to get back to you with a handful of changes. If your game was really polished, the changes would be pointless or even harmful things. I quickly learned to leave in a few obvious things that were trivial fixes, e.g. blocky bitmaps, misspellings, jarring colors. Instead of coming back with: > we really like the game, but couldn't the snake be an F-15 fighter, and couldn't the scrolling be vertical instead of horizontal? ...it would be more like: > Change that color, fix that icon, correct that spelling

deleted 8y ago
[deleted]
makapuf 8y ago
See also the story of the duck and the queen on game battle chess https://en.m.wikipedia.org/wiki/Battle_Chess https://en.m.wikipedia.org/wiki/Battle_Chess
- icc97 8y ago
  The source of that is from a codinghorror post [0] [0]: https://blog.codinghorror.com/new-programming-jargon/ https://blog.codinghorror.com/new-programming-jargon/
- yebyen 8y ago
  Came here to say this! I've told this parable of the duck before, but I did not know the origin of the story... "get that duck out of there please otherwise looks OK"
shoo 8y ago
similarly, in the context of nightmarish optimisation death marches to fit inside a memory budget -- see "the programming anti-hero" https://www.gamasutra.com/view/feature/4111/dirty_coding_tricks.php?print=1 https://www.gamasutra.com/view/feature/4111/dirty_coding_tri...

neumann 8y ago

I did this in our University laboratory for OHS, we called it window shopping. By giving the inspector a few easily visible, but not dangerous issues out in the open, he was satisfied we were up to scratch safety wise but could also tick all his little boxes. An out of date MSDS for chemicals we no longer had, a not tested and tagged electrical cable used prominently, a drink bottle left next to the lab computer by a student.

Graham24 8y ago

I've done this, leave an obvious trivial bug for the QA to find otherwise they'll keep digging until they find something pointless and hard to fix, which is not a problem in the first place. they have to find something to justify their jobs. I wonder if there's a name for doing this?

bklaasen 8y ago
That's a team-wide failure to understand business value.

cimmanom 8y ago

This is much scarier for a construction project than the game programming anecdotes that follow.