In my daily browsing of topics, I stumbled across a conversation on ‘coined programming jargon’. The conversation is well on it’s way to go beyond the 8 pages and appears to have started somewhere in or before February. I’m not sure how I managed to miss this one, but the terms coined are quite amusing. I might just have to go and start using them in my projects for when I need a lift.

Here are my personal favorites…

  • Pokemon Exception Handling – For when you just have to catch em all.
  • Yoda Conditions – The act of using if(constant == variable) instead of if(variable == constant), like if(4 == foo). Because it’s like saying “if blue is the sky” or “if tall is the man”.
  • 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.
  • Hindenbug – A catastrophic data destroying bug.
  • Bloombug – A bug that accidentally generates money.
  • Schrödingbug – A problem that some people see when they look and others can’t find at all. Often tied to the execution environment in a surprising way (or a cat).
  • Heisenbug – A computer bug that disappears or alters its characteristics when an attempt is made to study it.
  • Barack Obama – An [account or queue] that we assign our most aspirational tickets. Like stuff we’d really like to do with a project but will probably never get approval for.
  • Fear Driven Development – When project management adds more pressure by firing someone or something else of similiar shock factor.
  • Higgs-Bugson – A hypothetical bug predicted to exist based on a small number of possibly related event log entries and vague anecdotal reports from users, but it is difficult (if not impossible) to reproduce on a dev machine because you don’t really know if it’s there, and if it is there what is causing it.
  • Chunky Salsa – A single critical error or bug that renders an entire system unusable, especially in a production environment.
  • Hooker Code – Code that is problematic and causes application instability (application “goes down” often).
  • Hydra Code – Code that cannot be fixed. Attempts to fix any single bug will causes two new bugs to appear. In the end, it should be rewritten.
  • Ninja Comments – Comments that doesn’t exist in code where someone would normally find them
  • Code Slush – The date after which no changes will be accepted, except of course, all the changes that management will ask for at the last minute. Like Code Freeze but accepting of the fact that some changes will still get in.

Update 9/15/2014: Link is now dead, so it’s just you and me now. If you know about a longer list of these somewhere, let me know.