Thats Not Really An Issue

AntiPattern Name: ThatsNotReallyAnIssue

I have a little story:

A few months back, when we were holding a planning meeting for phase 2 of a software system, I presented the case for using optimistic concurrency to solve a potential issue involving two users making a change to the same data in our application. Being the most experienced person in a largely inexperienced team, I was told that, "That's not really an issue". Last week we started experiencing a "weird bug" on our live system involving data being lost when certain client details were updated simultaneously.

I think ThatsNotReallyAnIssue deserves to be called an AntiPattern.

Type: Organizational

Problem: Inexperienced team members running a project ignore concerns that they don't understand.

Context: Reviewing design decisions.

Forces: One or two experienced team members bring up a supposed "problem" with the design, that nobody else can see. In a consensus-based system, the majority of the team do not see the problem, and so see the experienced team members as obstructionists. In a top-down system, the manager or team leader makes the same judgment, and may hold the experienced members responsible for holding up the project.

Examples:

Problems well known in the academic literature, but not to self-trained coders.
Problems that will increase deployment pain, noticed by team members with system administration experience but not by pure developers.
Problems with human involvement, such as internal politics or massive LeadingRequest syndrome

Supposed Solution: Dismiss the concerns and ignore the problem. After all, if everyone (or the leader) doesn't agree it's a problem, it's not.

Resulting Context: The problem crops up in production. "I told you so" is not socially acceptable. Frequently, the problem is attributed to rushing the project, and to not enough involvement of the responsible managers.

Occasionally, those who can't see the problem miss many other problems. There always seems to be a devious problem that simply couldn't have been avoided, and the oddballs who predicted them end up in a giant snowball of blame for continually opening their smart mouths.

Solutions:

From the bottom:

If you can get away with it, fix the problem silently or prove it exists.
Mention the cause of the problem casually, but not the consequences. This leaves plenty of room for other egos to think they discovered the problem.
Encourage cultural or workgroup acceptance of Murphy's Law, especially regarding concurrency and distribution issues: At a billion meaningful operations per second, anything that has a one in a trillion chance of going wrong will happen every twenty minutes. Wherever communications can conceivably fail, they will fail.
Write tests that demonstrate the odds of this problem happening in production. Present this hard data to those in charge.

From the top:

Every project is individual. Those who understand the situation best are not those with general expertise, but those with tribal knowledge. Quit ignoring the tribal knowledge.

On an only slightly related note, always use the contraction "Isn't" over the contraction "It's not" or "That's not". Reason? "It snot." "That snot." These are audibly indistinguishable.

This is a legitimate issue, but there is a caveat. The very same people who predict problems often tend to predict dozens of problems based on perceived flaws in design that never occur. If one isn't careful, predicting too many problems results in the perception that one is "crying wolf." Further, it is impossible to fix all of these perceived "problems" within the constraints of any normal budget and time. It requires a significant degree of expertise to discern which items really are and not going to be real problems down the line. YouArentGonnaNeedIt comes into play.

I often get personal satisfaction by stating "I told you so". Experience is a useful but under-appreciated thing. However, doing so is usually not good for your career. ChoosingSatisfactionOverMoney.