Redesigning the Pipeline


Both continuous delivery devotees and those who enjoyed my DevOpsDays Silicon Valley 2013 talk may find this tidbit I saw in Wired a few months ago interesting: Key to Eliminating U.S. Flight Delays? Redesign the Sky Over New York City.

It’s an in-depth look at Mitre’s work with the FAA to redesign the airspace around New York City, which handles a ton of air traffic and has a number of unique requirements.

I found various elements of the project really interesting (and applicable to our industry):

  • One of the large components of the proposal involves increasing the coverage of the New York TRACON, to ease transition from Centers’ airspace to the runways. In other words, increasing the purview and involvement of those looking at the pipeline and doing system-level analysis and coordination provided a better way to solve this problem, given other resources remaining constant.
  • A lot of the modeling they’re doing is based on math that was used in nuclear physics; Damon Edwards’ statement that a lot of this stuff turns out to be “just physics: time, pressure, flow” seems to be spot on.
  • Part of the proposed solution is to increase the number of exit-gates by “fanning out” the departure paths. This increases complexity, which is bad, but it seems to be manageable in this case, given that amount of standardization within the system as a whole, providing more data for the assertion I made in my talk that a serious, consistent focus on standardization facilitates scaling.
  • The work done on redefining the pipeline’s paths did not forget the include the operators (air traffic controllers), and after consulting them, some seriously wrong assumptions were found in the computer simulation models.

The article closes with an interesting quotation:

“The airspace is the airspace,” the FAA’s Kelley says. “No one’s going to give us more of it. We just have to use it better.”

I think this is an often overlooked issue in IT, Operations, and Release Engineering work: most of the success stories that we hear about involve a conscious business decision to fund release engineering, Ops, and tooling teams at levels that are higher than previous eras. That’s an obvious (and somewhat easy!) solution to the problem.

But many organizations (startups) simply do not have or are not willing to allocate the resources necessary to realize those efficiencies. We can argue about whether or not that’s a prudent thing to do, but if we accept that constraint as real and immovable, this project suggests that a great place to use the resources available is to take a very close look at the organization’s software development and delivery pipeline, its operations, and operators.

This focus can result in improvements that, at first blush, look to be merely minutes, but taken holistically, have a very real overall impact to the entire system, its capacity, and ultimately, its users.