You've probably heard about the latest problems and delays with the much-heralded Boeing 787 Dreamliner. Already two years behind schedule, one of the test aircraft recently had a "modest" cabin fire. Note that is not just Boeing's latest aircraft which have had problems: the somewhat competitive, also extremely advanced Airbus A380 (which just entered service) also was several years late, and now has had some very serious engine problems.
The cabin fire, which had some electrical causes, is certainly scary, especially as it also caused the failure of some of the redundant control systems in the highly electronic airplane. Clearly, Boeing engineers and their subcontractors will investigate and make changes; in this case, according to a well-written story in The Wall Street Journal, the changes involve both circuitry and software, see here.
And that's what caught my attention. If "in space, no one can hear you scream" (refer to the tagline of the 1979 movie Alien for the details), then it is also true that "in aerospace, there are no 'small' changes", no quick-and-easy ECOs (engineering change orders). Any change—other than perhaps to non-critical items such as the color of the cabin—will require assessment, evaluation, verification, test, approval, and more. It's a very tough product-design environment, for all the well-known reasons. There is a severe ripple effect subsequent to any changes, and the law of unintended consequences is fully enforced.
I am not criticizing Boeing here, not at all; in fact, I admire their ambition, engineering prowess, and the risks they are taking on this project, with its extensive use of carbon-fiber composites; advanced electronics and mechanical design; use of a far-flung network of subcontractors; completely paperless design using advanced CAD, communication tools, and project management systems; and production tooling and techniques.
There's another lesson here for engineers, and more importantly, for those who depend on engineering success, whether for business or social-cause reasons. It is easy to forget that engineering progress in research, product development, production, and proper evaluation/test is not a linear, deterministic process.
That's why I strongly dislike the concept and mindset of a "roadmap". This is not because we shouldn’t have a plan, but because publicizing and promoting it implies that such progress is scriptable, predictable, and straightforward. It's especially aggravating when the advances that the roadmap calls out don’t happen as expected, and engineers are criticized for not delivering what they probably shouldn't have committed to in such a public way. ♦