On Dec 26, 2010, at 3:12 PM, Bob Paddock wrote: >>> Flexibility and specific applicability are not mutually exclusive, and for >>> the very reasons you are citing here. >> >> True, but what makes this possible? It's *avoiding* specificity in the >> foundations. > > I find that statement odd. If the foundation is not well specified > then it is not a foundation at all, it is jello.
Foundations must be well defined, yes. Sin[x] is an extremely well defined function, but it is not *specific* to any application. > > I'm curious about how exacting the specifications are for your space projects? They tend to start sloppy, because these are research projects, and if we knew what we would find, it wouldn't be research ;-) Part of the trick to a good project here is to be as agnostic as possible about what you might see. Avoid the tunnel vision of specific expectations, but at the same time create a solid, extremely well defined foundation. One of my proudest career achievements is the flexible data acquisition system (EDS) for the RXTE mission (http://heasarc.gsfc.nasa.gov/docs/xte/abc/pca_issues.html#struc). In the early planning, the data acquisition system architecture was a fine example of top-down design from notions of what the observing program might be. In other words, it reflected our ignorance of what was actually going on in the x-ray sky. It had a complex collection of specialized modes crafted to answering specific scientific questions. But a couple of us were disturbed by this. We came up with a parameterized architecture that could cover all of the kinds of observations that were contemplated, as well as "crazy" configurations that were generally considered useless. One "crazy" configuration was to reduce the number of bits/photon to one, and thereby achieve two orders of magnitude better time resolution than most people thought necessary while staying within data transmission restrictions. I'm told that this has been the most common configuration. Give people capability, they figure out how to use it! But give them what they say they want, they'll use it once, discover that they really wanted more than they said. RXTE's greatest discovery has been the extremely rapid rotation (~600 Hz!) of neutron stars in accreting binary systems. As originally conceived, with modes specifically targeted to what people wanted, RXTE could not have discovered this. But it not only made the discovery but spent much time (partially) unravelling what's going on here. The lesson is: don't be too specific about your desires when designing a tool. Instead, design the tool to cover the widest possible space with the smallest number of features. Then you can really go places. > > Here is an interesting document on specifying software from NASA: > > http://www.hq.nasa.gov/office/codeq/doctree/871913.pdf > > "The focus of this document is on analysis, development, and assurance > of safety-critical software, including firmware (e.g. software > residing in non-volatile memory, such as ROM, EPROM, EEPROM, or flash > memory) and programmable logic. This document also discusses issues > with contractor-developed software. It provides guidance on how to > address creation and assurance of safety-critical software within the > overall software development, management, risk management, and > assurance activities." But the real truth is that R&QA in NASA focuses on deflecting blame from management. We have rigorous bureaucratic procedures hiding endemic sloppy thinking. This costs massive amounts of money, and sometimes kills people. > > While gEDA and friends might not be considered 'safety-critical' by > many, there is no reason good software disciplines should not be used, > including good detailed specifications at all levels. But a toolkit should avoid overly specific targets within the application space. Cover the space with simple tools rather than implementing ad hoc complexity for specific purposes. That makes for a *more* solid foundation. John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ [email protected] _______________________________________________ geda-user mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
