On Dropping the [Pipes]

02/03/2012

@cheeseplus¹ pointed me to a post this week by the always-engaging² Bruce Schneier covering yet-another Transportation Security Agency snafu.

Schneier’s summation of the event:

1. TSA screener finds two pipes³ in passenger’s bags.
2. Screener determines that they’re not a threat.
3. Screener confiscates them anyway, because of their “material and appearance.”
4. Because they’re not actually a threat, screener leaves them at the checkpoint.
5. Everyone forgets about them.
6. Six hours later, the next shift of TSA screeners notices the pipes and — not being able to explain how they got there and, presumably, because of their “material and appearance” — calls the police bomb squad to remove the pipes.
7. TSA does not evacuate the airport, or even close the checkpoint, because — well, we don’t know why.

I noted how this felt like there was a strong analogy to be made to how some release engineering teams go about their work.

But in the moment, there was just a nagging sense of that. I spent some more time thinking about why, exactly, this was so reminiscent:

• Conceptual Inconsistency: The screener initially deemed the items were not a threat. But wait, then they were. So they were confiscated. But then they weren’t actually treated like a loaded gun⁴ or remediated in any meaningful way.
  
  These types of cognitive inconsistencies present a real problem for others (especially engineers) trying to assess the reasoning behind procedures and process. In the TSA’s case, “because we said so” is a reason that sticks. It’s a less valid reason in the majority of other venues, including the one we operate in.
  
  When we’re inconsistent, we provide so much ammo to be taken less seriously. Or ignored completely.
• Queue management: presumably the reason the screener left the (supposedly) dangerous items lingering at the checkpoint was because he became distracted. Like a lot of release engineering tasks, screening passengers is inherently interrupt-driven. The fact that the security checkpoint’s operations are structured such that a (common and constant) interruption was allowed to, in effect, compromise the entire purpose of the checkpoint, indicates that there’s a queue management issue that needs addressing.
• Follow through: So obviously the ba, er pipes were dropped when they weren’t dealt with as any other threat. What is especially interesting, though, is that when the initial inconsistency was detected, the TSA didn’t follow its own procedure for addressing the problem. This, again, creates an inconsistency and credibility issue, in addition to the obviously embarrassing operational one.

At the end of the day, these types of (seeingly ongoing) occurrences only serve to reduce the credibility of the TSA, and support the argument that it’s all just security theater that offers no real value or benefit.

The effects of those same credibility-reducing actions represent a very real issue for build teams operating in similar ways: when events like this happens, it’s much easier for others to assume that all we’re engaged in is “release engineering theater.”

It’s an important lesson about a class of traps we need to be conscious and vigilant of avoiding, and need to design procedures that inherently address them.

And then commit to consistently executing those procedures.

_______________
¹ Who can argue with a sentiment involving more cheese?
² And often amusing
³ Pipes? Really? This feels like a GTA mission already
⁴ Y’know, any other threat