Microspeak: Break glass

During the product endgame, the ship room accepts fewer and fewer bugs, until you reach a point where the product is basically finished, and only a catastrophic issue would be accepted for a bug fix.

But it’s not that teams have stopped doing work. Bugs are still being reported, and teams investigate and assess the problems and the potential fixes. Even if the fix doesn’t get accepted by ship room for the initial release, it can be brought to the servicing team for incorporation into a future update.

Recently, the term “break glass” has gained currency for the case of accepting a change to a product that everybody thought has reached its final build. As a result, the build lab has to spin up one more build, everybody has to update their documents where they had written what they thought was the final build number, and a new round of testing begins.

The metaphor is that the final build is sealed in a box, and the button to open the box has a glass cover that reads “In case of emergency, break glass.” Accepting the change means that somebody has to break the glass and open the box.

For some reason, the phrase “break glass” is not declinable. You don’t say “break the glass” or “broken glass”. The phrase is frozen, and you have to circumlocute around it:

• “Is this a break glass scenario?”
• “I don’t want to break glass over this.”

You are probably already familiar with the terms show stopper and ship stopper to describe the situations that lead to the breaking of glass.

Bonus chatter: It appears that the services teams use “Break Glass” to describe an emergency process to address a major service outage, in which temporary secure access to server resources is granted through some secondary means. These emergency processes must naturally undergo their own security review. It also follows the metaphor of the glass cover over a button that says “In case of emergency, break glass.”

Bonus reading: Losing the game of Last Checkin Chicken two products in a row.