On a recent flight I was sitting in an exit row aisle seat when the Flight Attendant came up to give us the standard speech.
"Are you willing and able to carry out the procedures outlined in the emergency card?"
One by one people met her eyes and said, "Yes."
Then the woman next to me, who spoke little English, took her turn. She said "No!"
I'd never heard someone say that before.
From the look on her face, neither had the Flight Attendant.
She stammered, "You mean you're ready and able to operate the door..."
The woman shook her head and waved her hand. "No!"
The Flight Attendant hesitated. Every seat on the plane was taken. We were ready for an on-time departure. Rain clouds were threatening.
I could see her thinking, "If I take the time to swap this lady with someone who can take an exit row seat, we're going to miss our departure window and sit on the freaking ground for an hour, my butt will get put through the wringer for not asking the exit row question sooner, and every passenger on this plane is going to be angry."
After just a few seconds of these thoughts she told the woman, "You mean Yes," and proceeded down the row with the rest of us.
My jaw dropped. But I had to admit she'd accurately assessed that our chance of crashing without dying instantly on this particular flight was very low.
So she risked a hefty FAA fine and didn't do it by the book.
As I often ask in these pages, what does this have to do with game development?
Software testing has a lot in common with maintaining an airplane. So much in common that failure in each case is defined by the same word: crash.
There are lots of carefully defined procedures you have to follow. In theory, a single significant problem means you don't go anywhere until it's fixed.
With packaged console games the stakes are very high. If Call of Duty crashes two hours into the game millions of defective copies will have to be replaced, with losses in the tens of millions of dollars.
PC games, which can be patched online, have grown more casual about code releases, so much so that PC game players now see game patches as normal... a big change from 20 years ago.
The growth of online games and DLC have loosened these standards still further, especially for non-fatal bugs. Why sweat it when we can fix it tomorrow?
The Producer thinks, "If I take the time to fix this bug and run a complete new test pass, we're going to miss our release window, Sales and Marketing will have nothing to sell for two more days, my butt will get put through the wringer for not finding the bug sooner, and every manager in this company is going to be angry."
Sometimes the tester says "No" and is told, "You mean Yes."
The dev team, like the passengers on the plane, is shocked when someone in charge cuts corners on a key safety rule.
Sometimes that shock does more damage to the team's future quality commitment than any bug ever could. But nevertheless the calls get made.
And that's why, as the headline says, Some Game Companies Have More Glitches and Patches.
Do you disagree? Use the comments box below to share your thoughts.
Copyright (c) 2010, Don Daglow. All Rights Reserved.

The flight attendant in your story is indeed analogous to the publisher producer. Trust me, I've had to make these decisions though I would like to think the nature of the bugs that shipped weren't as critical to the user's enjoyment of the product as a person's inability to operate the emergency door on a plane is to the well being of passengers in an airplane crash.
I would argue, however, that the dev team is equally complicit in this process. Whether this is an indictment of the overall business model of our industry, is for another conversation or future blog; but the commitment of a dev team and publisher to scope within the agreed upon schedule is very much a collaboration and conscious choice of both parties.
Posted by: Tim Ramage | October 22, 2010 at 11:49 AM