I recently flew into Washington Dulles airport, and I was struck anew with the sheer impracticality of the Dulles “mobile lounge.” It’s like something out of Star Wars. I can only imagine the glee of the Chrysler salesman who, in 1962, sold the Dulles airport authority a fleet of these whimsical things.
You may think that modernist-era people movers have very little to do with embedded engineering. You’re basically right—but stick with me, because there’s a worthwhile point here.
Mobile lounges are 54 feet long by 16 feet wide, travel at a top speed of 25 mph, and can move just over 100 passengers. Today, 19 mobile lounges are used to connect the Dulles main terminal with some of the other terminals. When a mobile lounge nears its dock, the entire passenger compartment scissors up, which is so much easier than building a ramp, I guess.
The whole thing isn’t sensible, on so many levels. Hard cost data is difficult to come by, but just think about it:
* The upfront engineering effort must have been nontrivial; mobile lounges, with their scissor lifting mechanism and odd size, are not particularly similar to anything else Chrysler was likely to have had lying around in the late 1950s.
* The per-lounge cost, especially in low volume, must be pretty high.
* Maintenance on these beasts would be a specialized skill, and spare parts must be hard to come by, especially after so many years.
Why mobile lounges?
Evidently, Eero Saarinen—the great modernist architect who designed Dulles airport, JFK airport and the St. Louis arch—is to blame for the mobile lounge. Saarinen wanted to do away with the long distances that people have to move through large airports, and he didn’t like the cost of the finger-like “jet bridges” found in typical airports, either. He conceived of the mobile lounge as a way to move people from a central point directly to their aircraft while affording airport management several operational benefits.
Of course, a system of ordinary buses could have met the same goals. According to the same book quoted above, in the early 1960s, some European airports used buses to take passengers to their airplanes, but Saarinen didn’t like the bus approach because it required passengers to climb stairs, and it exposed them to the weather and the loud sound of airplane engines.
An alternate approach
I’d guess that in the early 1960s, it would have been possible to design a covered, portable escalator that could whisk passengers from the door of a bus up to an airplane door—far less expensively than designing the brand-new mobile lounge.
Think of it as a choice between an evolutionary and revolutionary approach. The evolutionary approach would have been to take a well-understood, de facto standard—the city bus—and extend it with a new accessory, like a portable escalator. But Saarinen chose the revolutionary approach, and he ended up reinventing the wheel, badly.
Which brings us around to the embedded engineering space. Different engineering teams have different cultures. Joel Spolsky recently stirred up a hornets’ nest of trouble when he suggested that the best programmers were those who ignore grandiose theory in favor of a make-it-happen approach:
“Jamie Zawinski is what I would call a duct-tape programmer. And I say that with a great deal of respect. He is the kind of programmer who is hard at work building the future, and making useful things so that people can do stuff. He is the guy you want on your team building go-carts, because he has two favorite tools: duct tape and WD-40. And he will wield them elegantly even as your go-cart is careening down the hill at a mile a minute. This will happen while other programmers are still at the starting line arguing over whether to use titanium or some kind of space-age composite material that Boeing is using in the 787 Dreamliner.
“When you are done, you might have a messy go-cart, but it’ll sure as hell fly.”
Now, I would never describe the end result of our engineering process as “a messy go-cart,” but despite that one quibble, I mostly agree with Spolsky. There are appropriate places for innovation and design. But most of the time, business goals are best served by a city bus instead of a mobile lounge.
The trick is often to find the appropriate existing core—be it an open-source project, a standard component like DirectShow, some licensable intellectual property, or a city bus—and then extend it. Sticking with proven components based on open standards ultimately means a quicker time to market, lower ongoing maintenance costs, and a more elegant solution.
Howdy Pierce, managing partner and Cardinal Peak co-founder, is a “video guy” whose technical background is in multimedia systems, software engineering and operating systems.