Re: Space Access Update #112 9/19/05


Len wrote:
> Dr John Stockton wrote:
> > JRS: In article <ti92m1t86lp51j6pvnsdpoek1cb38pgv08@xxxxxxx>, dated
> > Thu, 27 Oct 2005 19:39:14, seen in news:sci.space.policy, Monte Davis
> > <monte.davis@xxxxxxxxxxx> posted :
> > >
> > >Without such a loan, though, the challenge is to find an economically
> > >viable path *from* where we are today *to* the promised land of CATS.
> > >It's a tough challenge that's almost certainly going to require a long
> > >series of incremental nibbles at the problem from technology AND
> > >politics AND alt.space entrepreneurial economics... not a "silver
> > >bullet" breakthrough from any one angle.
> >
> > That is why it is wrong to concentrate on designing (which in this field
> > means "not very expensive") to do cheaply such as : orbit loads of
> > tourists; supply ISS; launch satellites; launch interplanetary vehicles
> > or components.
> >
> > Instead, the aim should be primarily, by showing the design, to get
> > enough money to develop, build, and launch it, and secondarily that its
> > success should advance the cause of affordable access in some way or
> > another. If the first is achieved, the second is near-inevitable.
>
> While I generally agree that the main path should be
> going for the money, one should not dismiss easily the
> importance of conceptual design early in the game. This
> is true for two reasons: 1) A good design may--not always
> --help get the money; 2) Once serious money starts to be
> spent, then all opportunity for thinking on the conceptual
> level is gone; all effort then goes into detail design of
> the existing concept, right or wrong.
>
> This is one of the things that has gone so wrong with
> procurement. There used to be far more opportunity for
> relatively free-structured exploratory study. Now the
> emphasis is on total package procurement, without ever
> figuring out a basically good approach. What passes for
> exploratory study these days tends to be limited to someone's
> preconceived notion of a good approach to a basic need or
> problem--rather than a wide-open investigation of the basic
> need itself (contrary to OMB A-109).

I don't know, from my perspective it is actually an overemphasis on
studies and requirements justification that has resulted in a
excessively long, underwhelmingly successful process. The exploratory
studies that tend to focus on long-range technology forecasts and
'stretch' requirements result in overblown, underbudgeted requirements
that end up being undoable. Witness FIA. Witness SBIRS low. SBIRS high.
Advanced Wideband Commuications Architechture. Joint Tactical Radio
System. Other unmitigated disasters are in the making, I guarantee.
The hits go on. What they all have in common is that they followed a
rigorous, careful 'study and analysis' process, which focused on trying
to carefully decide the exact right way to do things, then justifying
it, etc--still to find themselves horribly unrealistic with regard to
estimating what could be accomplished and how much it would cost.

I think what it tends to come down to in the end is two things--first
an arrogance that you can somehow predict the future. We build these
systems that are going to take 10 years to get into orbit. Knowing
anything we start building today will be obsolete by that time, we
build in upgrade periods DURING THE DESIGN PROCESS, or we insist on
requirements that we're not sure we'll be able to meet, based on some
loose parametric analysis of technology trends. This is usually at the
technical level, where we say 'we know we can't do X today on orbit,
but given current trends, we will be able to do that on orbit before we
get to that point in the program...' Then when our technology falls
short of expectations, we have to scramble to provide a tenth of what
we intended to do. By the same token, sudden upgrades often cause
programs to veer well into the building process, which causes even more
delays and increases in cost.

The second thing we tend to do, even as we assume we'll have have
nearly obsolete satellites even before we launch them, is we somehow
think by understanding this concept, we can therefore ignore the
reality of that fact. This is what causes us o overreach with
requirements. Since we don't know how to do what we want to do, we just
make it a 'requirement' to do what we want to do, as if this will
magically make the solution feasible economically or technically.

What we need in the government is 'reality based requirements,' an
understanding from the beginning of the conceptual process that every
requirement has a technically feasible corollory. The only way to do
this is to limit the design-to-fly time to a period of under 5 years.
Anything longer, the technology is obsolete by the time you launch it.
Anything that length or less, even if it doesn't work exactly the way
you envisioned it, at least you can launch an upgraded replacement
before going too much longer.

tom


>
> Best regards,
> Len (Cormier)
> PanAero, Inc.
> x@xxxxxxxxxxxxxx (change x to len)
> http://www.tour2space.com
>
> >
> > One need not otherwise bother about cheapness; if the money to do it is
> > neither obtained from Government, nor obtained by the major business
> > entities, then cheapness is a necessary consequence.
> >
> > --
> > © John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 MIME. ©
> > Web <URL:http://www.merlyn.demon.co.uk/> - FAQqish topics, acronyms & links;
> > Astro stuff via astron-1.htm, gravity0.htm ; quotings.htm, pascal.htm, etc.
> > No Encoding. Quotes before replies. Snip well. Write clearly. Don't Mail News.

.

Relevant Pages

  • Re: Space Access Update #112 9/19/05
    ... Tom Cuddihy wrote: ... >>> enough money to develop, build, and launch it, and secondarily that its ... >> importance of conceptual design early in the game. ... > loose parametric analysis of technology trends. ...
    (sci.space.policy)
  • Re: NASA Space Shuttle - The Real Problem
    ... Saying the "shuttle runs on old obsolete technology" is a red herring and should be labeled as such. ... A launch of December 2006 means the hardware has to be delivered to Kennedy Space Center by June 2006. ... That means the prototype initated tests around June 2004, so the tests can be run and evaluated in time to start construction of the flight unit. ... *no significant design changes after the breadboard*. ...
    (sci.physics)
  • Re:Urgent requirement for Java developers.
    ... Identifies key business and technology drivers that impact application ... and application design, coding and design standards, best practices, ... application of techniques and standards such as service-oriented ... Expert level on Java J2EEdevelopment knowledge (5+ years on J2EE ...
    (comp.lang.java.beans)
  • Re: staging, reliability, etc. (was Re: Towed Booster Stability)
    ... One D III failure was due to poor judgement by the company in not expending ... of the first flight. ... They appear to now have a mature design and operation. ... But launch ...
    (sci.space.policy)
  • Re: Microsoft Zero Day security holes being exploited
    ... MS has flirted with *NIX in the past, from Zenix in the days of MS-DOS ... If anything, the upgrade cycle of NT is more forgiving than Win9x, ... in fact it's worse than that; they design purely for pro ...
    (microsoft.public.security)