Visibility Gets You Shot

This is an AntiPattern experienced on a daily basis.

If you make a problem visible, you will probably be the one tasked with fixing it. It's a ShootTheMessenger effect.

Real examples, recently experienced:

I added some debugging info in a "can't happen" section of the code. It would've been easier to just ignore that condition, but I thought, what the heck... I'll make it helpful just in case it does happen. 5 minutes later, a coworker emails me, asking this: "Debugging info in production code?".
I did an ExtractClass for a "Tree" class. Previously, there was a method that looked like "allPathsForTree", which became "Tree>>allPaths". 5 minutes after I created the new class, a coworker emails me, "Why are we reinventing the wheel? There are dozens of downloadable Tree classes."
I am the only one who writes any significant unit tests on a particular project. The management saw that I was doing MockObjects, and made an edict, "No MockObjects, because that means the database itself isn't tested." I'm wondering why no tests at all are a smaller problem than 80% tests. (This item is particularly silly, because I have end-to-end tests in addition to the unit tests that /do/ ensure that the database is working.)
...

Hmm. PartialVisibilityGetsYouShot?.

Clearly, your colleagues or managers don't seem to catch the whole context of such sudden enhancements of visibility. Complaining that "testing only x sucks because that means y is not tested" while in fact nothing is actually tested proves that the project is not measured correctly anyway. So the problem is not in revealing one flaw (into what could else be a good development process) but trying to correct things in a development culture that is grounded on telling and blaming. Leaving things hidden would surely get the project shot sooner or later. So admittedly, ShootTheMessenger may be an AntiPattern. However, it's not visibility that gets you shot. Stupid managers shoot you when you try to get things better; for many reasons that don't all relate to Visibility.

Yes, this is a ManagementAntiPattern, instead of a DeveloperAntiPattern?. Maybe an alternative name would be PunishVisibility?.

Analogous to TallPoppySyndrome - the tallest poppy get mowed.

The nail that sticks out gets hammered -- supposedly a popular proverb in (communist) China. (And actually a popular product in conformist Japan)

Many authors on this wiki like to explore programming outside the bounds of the prevailing dogma. Following advice from this site could get you shot.

I had this problem several years ago. I was working on a contract to help out an inexperienced team developing an embedded system in C. The legacy code was clearly full of serious bugs, but when I drew their attention to them I was told "it has been working perfectly for 2 years". They hadn't associated the continual random crashes with 'imperfect' code. The code was often easy to fix and test. But they didn't appreciate me writing test code that made the legacy stuff crash - to demonstrate the problem. I got a 'well DontDoThat then'. I fixed it anyway.

-- DaveBerkeley

I think the "Debugging info in production code?" and "Why are we reinventing the wheel?" questions at the top of the page are legitimate concerns. I wouldn't consider myself "shot" if a co-worker raised them. I'd give them serious consideration. Visibility leads to more responsibility and action, but that's a good thing. -- EricHodges

For Eric: I don't know the policy that company had for "debugging info in production code", but it obviously didn't make "production" after fifteen minutes. The fact that it wasn't working as advertised is at least as big a problem as "debugging info in production code". And he didn't "reinvent the wheel", he extracted the wheel that somebody else reinvented. -- RobMandeville