As we approach 20 years of the Hubble Space Telescope, the subject of why it broke and how it was fixed continues as a favorite topic on the lecture circuit. Recently, I was invited to a panel discussion with the broad topic of quality in engineering – in this case software, at DVCon in San Jose. The audience of a few hundred was there to discuss methods for identifying and maintaining software quality. When I was invited, I pointed out I know none of the industry acronyms, but, the organizers were undeterred. Joining me on the panel were a series of what I would call working Vice President’s, meaning they rose up through the ranks as an engineer, as I have. This made for an excellent mix and perspective relative to the interests of the audience, which from my vantage point appeared to be those with 5-10 years in the “working” world.
The event was entirely unscripted, other than the moderator having a backup set of prompting questions initially to get the audience engaged and later to step up the pace should audience interest start to lag. Now, I am not historically a fan of panels and rarely attend a panel discussion format event. To mention an exception, the yearly Emerging Technology panel at MIT has consistently brought together the best of the best in a forum where they speak candidly on topics that are relevant. I highly recommend this event.
Now, it seems that between the five of us on the panel, plus the moderator, we established a synergy that emulates the standards I experienced with the MIT panel and a rapport with the audience that encouraged and achieved a true group event. The audience engaged quickly and asked challenging questions, to which the moderator orchestrated our responses to keep them terse, relevant, and engaging. The questions represented their real challenges in understanding their real environment. What was rewarding was, it did seem that we at the front really had “been there and done that” and could offer the questionee a perspective that did cause them, as well as many in the audience, to pause and move ahead in their understanding of the environment that surrounds them on a daily, weekly, and monthly basis.
I was encouraged to use the Hubble 1st Servicing Mission story (never to be called a “repair” mission) as a context for any comments I might be inclined to make. As a result, I established early on the evolving theme, which I initiated at the University of Rochester two years ago and at SPIE Annual last summer, that the days of engineering of any flavor in the ideal world needs to be put away. Working engineers, especially the evolving generation, need to think and act defensively. Specifically, while your contribution will of course be perfect, the environment which your contribution will be placed in will be flawed in a many, many ways. The Hubble primary mirror being an excellent case history, but it is one of so many, that I have to conclude this is a pervasive flaw in our model of the world of engineering as a whole.
Of course, hindsight, as “they” are known to say, “is 20-20”. (A digression – if you are an American born and raised engineer, working in America, it is worth realizing that many, if not most of these colloquial expressions are truly meaningless and quite disorienting to the majority of the audience, who are not in the category described above). So, rather than dwelling on the mistakes of the past, what can be applied to the future. In my case, I have directly managed, (usually 1:1 with another PhD in my field and on my staff) over 2,000 projects for over 500 companies. In addition, I was on the Hubble repair team (but by luck, not the Hubble “breaking” team) and I have in my background other experiences that are even more expensive than the Hubble repair. From this I of taken the following insights into being a substantial contributor in complex technical environments.
First, of course, you do all of the basics, obsessively.
A) You communicate the parameters that govern the problem you are working on (Table 1 in optical design/engineering speak) in writing, with every external communication.
B) You determine your assumptions, ESPECIALLY in today’s science, your most basic assumptions. Does 2+2=4 (not necessarily).
C) You find two independent ways to check a calculation, preferably with completely different tools
But, and here is what is new, you do not have the luxury to do everything twice (and we are assuming the business model is not the one where it was recognized that repairing a failure, even one you caused, can be a valid source of substantial revenue).
Where do you focus your attention?
You focus on what is the project doing for the first time. A consistent failure path is where the new aspect of the project changes an assumption that has held for all time, until the day the project starts, and, you did not “think” about. I have example after example after example after example … (you probably get the point).
I give a one hour lecture with some of these examples, and, perhaps I’ll bring some to this to blog space, in the future.
In the meantime, I hear they have posted the entire panel discussion on the Internet, not that I have checked it out.
http://dvcon.org/2011_Panel_Session
I am more than happy to propagate this conversation, should anyone have insights or great stories to add. Also, if you have a local society or other forum, and this sounds like an interesting talk, I enjoy speaking on this topic, and I seem to be somewhat global these days.