Running the Pre-Release-Roll Numbers
Launching a 350+-ton peice of metal-loaded-with-people-and-cargo is a bit of a technical feat, not entirely unlike shipping any reasonably complex piece of software.
 Boeing 737 airspeed indicator section of the primary flight display |
That’s why those doing it day in and day out focus so much on procedures designed to increase the odds of repeatably successful outcomes.
One of these procedures is “getting the numbers,” values that directly inform pilot behavior. Numbers that don’t change are memorized. But for those that do, due to weight, locale, or weather conditions, pilots derive these values for every single takeoff1
One of these values is the so-called V1 speed; put simply, it is the speed of the aircraft during the takeoff roll at which, immaterial of circumstance, the pilot will continue the takeoff.
This is most often because this is the speed at which the length of remaining runway isn’t sufficient to safely stop the aircraft, but there could be other factors. But the important point is once this speed is called out2, even if an engine falls off, the pilot will take off.
There is an interesting analogy to release engineering: every product a software shop releases also has a “V1 speed”: the “velocity” the release reaches at which point the bits will go out the door.
This “V1 speed” usually isn’t defined by release engineers. It’s more commonly the purview of project managers, VPs, or business stakeholders3.
As a release engineer, it’s important to have an intrinsic sense of the V1 speed for each product you’re responsible for shipping. It’s one of the first values I try to calculate in new environments. Just like a pilot, it provides information that helps to inform engineering responses.
Once a sense of it is derived, working to codify the criterion that define the V1 “speed” for your release is extremely useful. I advocate such details be codified in the release checklist, in such a way that it everyone can clearly see at which point, and for what reasons, the team will abort a takeoff release, and more importantly, the reasons for which it will not4.
Exceptions, even in practice, should be rare, since encoding these criterion into your release checklist should account for serious issues-at-takeoff-release that the product can—and cannot—ship with5.
 “Set takeoff thrust.” |
Finding your own product’s V1 speed will make every release simpler and more routine.
More importantly, it eliminates an entire class of release-related communication and coordination when things are going well, and significantly reduces the complexiy of those conversations when things aren’t.
_______________
1 If you listen to the tower frequency of any busy airport, you will invariably hear a plane request extra time to “Get the numbers.” They’re referring to this process.
2 Calling them out verbally is also part of this process; it’s hard to hear, but you can hear V1 called at 1:36
3 Optimally, of course, this “value” is an amalgum representing requirements from all groups involved in the software development process
4 Opting to ship an update instead
5 To reverse analogize, the Continental 1404 incident or the American 191 crash provide a good estimation of equivalencies for the types of catastrophic release-failures one would file under “exceptional events”; all others can reasonably be accounted for, and should be.
The two incidents in the last footnote are quite impressive — never heard of either before, much obliged that you’ve pointed them out to me. The second in particular is especially mind-boggling.
(And if I’m going to take the trouble to comment…”catastrophic” in that same footnote.)
@Jeff:
Yeah, American 191 was an interesting accident because it was the first in a class of DC-10 accidents which illustrated some very serious fundamental design flaws with the type. The venerable United 292 crash again emphasized those design flaws (with loss of life).
(The DC-10 and the MD-80 are two aircraft I try to avoid as much as possible.)
What is also notable about 191 is that it was directly responsible for modifying the checklist procedures used and trained on for engine-failure-on-takeoff situations (beyond the type).