View from the Peak
Mobile Lounges and Development Methodology
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.
I didn’t have the presence of mind to snap my own picture of a mobile lounge, but Flickr user Afagen has graciously shared this photo under a Creative Commons license.
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.
Tags: development, engineering, methodology
2 Responses to “Mobile Lounges and Development Methodology”
As a software engineer, I try to follow the KISS principle: brute force has a lot to recommend it, not the least of which is that it is easy to understand. Elegance tends to be obtuse and easy to break during the maintenance phase. What I recognize in the mobil lounge concept is a brute force approach: Chrysler may not have had the different pieces of the mobile lounge laying around but the thing is, it was all off-the-shelf technology.
Start with a bus (or maybe a truck) frame, a simple box to carry the people with and a scissor jack to connect the two. The scissor mechanism may have needed to be up-scaled but it was (and is) in common use for material handling. The only real “engineering” was rigging the driving controls so they would work even though the lift mechanism changed the distance between the driver and the power train/suspension. And most of that is probably cable actuated: more off-the-shelf technology used for throttle and automatic transmission control in that era. I don’t know what they actually used but hydraulic steering would be another off-the-shelf technology that would fill that nich. Hydraulic or air brakes, both in common use at the time, and plenty of hose rounds out the engineering.
Maintenance probably isn’t a big issue; there are certainly no unique skills here. Basic maintenance is no different than any truck or bus and hydraulics can be complex to design but basic maintenance wouldn’t be beyond a competant mechanic. Engine and transmission parts may be difficult to find after nearly 50 years but, again, no more so than for any truck or bus of that age (and there are a few of those still on the road). If anything, given the slow speed of these people movers, the mechanicals will probably last just short of forever.
At least as I envision it, there is nothing about a covered escalator which would, a priori, recommend it: it is more off-the-shelf technology but I don’t preceive it as any simpler or cheaper than the scissor mechanism (it certainly seems a more complex mechanism), wouldn’t be any cheaper/easier to maintain than the current system and seems like it might have a higher center-of-gravity and handle more poorly (not that the current version handles well).
In retrospect, I suppose using a bus to pull a trailer with the covered escalator has certain advantages inasmuch as you could swap out either unit for repair/replacement without affecting the other. But maneuvering the trailer requires additional driving skills and I don’t think Chrysler would have been much interested in selling a system where they didn’t provide both halves of it and they weren’t in the escalator business.
By the way, Dulles is not the only place these are used; I first encountered them in Mexico City in the early 80’s.
Obviously, the decision to create and employ mobile lounges was not based on economic efficiency. I am sure that part of the reason these were selected was “impact” – the impression such system could produce. Anyone can use an off-the-shelf bus, but here in the bustling capital of the forward-looking United States of America, we advance to mobile lounges.
Consider the era when this was created; the hubris implied by John Kennedy’s “we choose to do these things, not because they are easy, but because they are hard.”
Equally, I have found that the decision in software design strays into “we can build it to do exactly what we want” once an initial problem or limit is hit using an off-the-shelf base product. They can also be led in that direction by a need to be flashier an dsplashier than anything that currently exists in production (by a competitor).
This approach often his its own set of problems to resolve, more than figuring out how to extend an existing technology would have. But the engineering team by then has invested itself into their own creation.
Mitchell Schwartz,
Technical Writer and observer of the software engineering development process
