wmartin@st-louis-emh2.army.mil (Will Martin -- AMXAL-RI) (03/30/89)
The following posting just showed up on the latest RISKS Digest; I checked the past SPACE Digests and didn't find it there, so I'm sending in a copy to get the information over here. If it turns out to be a duplicate, my apologies. The info in here is alarming. Considering the enormous slippage in the HST launch date, it is rather incredible. It appears that if the HST had been launched on time according to the original schedule, it could not have been used due to this software problem! So all that delay was not necessarily a bad thing. Yet the entire system may STILL not be ready, even after having given the software side vast amounts of extra development time during all these years of delayed launch. This is very depressing... Will Martin Item from RISKS: Date: Tue, 28 Mar 89 14:57:02 PST From: eggert%stand@twinsun.UUCP (Paul Eggert) Subject: Will the Hubble Space Telescope Compute? M. Mitchell Waldrop's article (_Science_, 17 March 1989, pp 1437-1439) on SOGS is notable for its coverage accessible to the general scientific public, and for its claim that the software engineering community has switched to rapid prototyping. Selected quotes follow. -- Paul Eggert, Twin Sun Inc. <aerospace.aero.com!twinsun!eggert> Will the Hubble Space Telescope Compute? Critical operations software is still a mess--the victim of primitive programming methods and chaotic project management First the good news: two decades after it first went into development, the $1.4-billion Hubble Space Telescope is almost ready to fly.... But now the bad news: the Space Telescope Science Institute in Baltimore still has dozens of programmers struggling to fix one of the most basic pieces of telescope software, the $70-million Science Operations Ground System (SOGS).... It was supposedly completed 3 years ago. Yet bugs are still turning up ... and the system currently runs at only one-third optimum speed.... If Space Telescope had been launched in October 1986, as planned at the time of the Challenger accident, it would have been a major embarrassment: a superb scientific instrument crippled by nearly unworkable software.... [chronology: 1980-1 2"-thick requirements doc. written by NASA-appointed committee 1981 contract awarded to TRW; peak team included 150 people 1983 first software components delivered later SOGS declared utterly unsuitable.] The problem was basically a conceptual one. NASA's specifications for SOGS had called for a scheduling algorithm that would handle telescope operations on a minute-by-minute basis.... The tacit assumption was that the system would schedule astronomers on a monthly and yearly basis by simply adding up thousands upon thousands of these minute-by-minute schedules. In fact, that tacit assumption was a recipe for disaster.... The number of possible combinations to consider rises much faster than exponentially.... In the computer science community, where this phenomenon has been well known for about 40 years, it is called ``the combinatoric explosion.'' Accepted techniques for defusing such explosions call for scheduling algorithms that plan their trips with a road map, so to speak. And SOGS simply did not have it. In addition to performance issues, however, SOGS was also deficient in basic design terms. ``SOGS used last-generation programming technology,'' says one senior programmer.... ``SOGS was designed in such a way that you couldn't insert new releases without bringing down the entire system! For days!'' says the science institute's associate director for operations, Ethan Schreier.... Indeed, the fundamental structure of SOGS is so nonmodular that fixing a bug in one part of the program almost invariably generates new bugs somewhere else.... So, where did SOGS go wrong?... One of the main villains seems to have been the old-line aerospace industry approach to software development.... In the wider computer science community this Give-Me-The-Requirements approach is considered a dismal methodology at best... Modern programming practice calls for ... a style known as ``rapid prototyping''... Even more fundamental ... few people at NASA were even thinking about telescope operations in the early years.... the Space Telescope project as a whole was saddled with a management structure that can only be described as Byzantine.... At the hardware level the chaos at the top was reflected in a raft of independently developed scientific instruments and onboard computers, none of which were well coordinated with the others. Indeed, the presumption was that any such problems would be taken care of later in the software.... So, is SOGS fixed now? Maybe. With TRW's help, the institute has spent the past several years beating the system into shape.... On the other hand, such progress has come at a price. SOGS now consists of about 1 million lines of programming code, roughly ten times larger than originally estimated. Its overall cost has more than doubled, from $30 million in the original contract to roughly $70 million.... In both NASA and Pentagon contracting, the cost of the old-line approach is becoming all too apparent. Indeed, it has become a real sore point in the computer community. ``It's the methodology that got us to Apollo and Skylab,'' says [James] Weiss [data systems manager for Space Telescope at NASA headquarters]. ``But it's not getting us to the 1990s. The needs are more complex and the problems are more complex.'' ``SOGS,'' he says, ``is probably the last example of the old system.'' ***End of Posting***