[mod.politics.arms-d] Arms-Discussion Digest V6 #18.3

ARMS-D-Request@MIT-MC.ARPA (Moderator) (01/11/86)

Arms-Discussion Digest              Saturday, January 11, 1986 12:06PM
Volume 6, Issue 18.3

Today's Topics:

See 18.1

----------------------------------------------------------------------

Date: Sat, 11 Jan 86 10:06:54 EST
From: Herb Lin <LIN@MC.LCS.MIT.EDU>
Subject:  Complexity measures


               From: Jim McGrath <Mcgrath%mit-oz@mit-mc.arpa>

               The problem I have with
               this debate is that the anti-SDI people are not addressing
               either of these two points adequately.  On the former,
               people have been concentrating on size of code for SDI.

          From: Herb Lin <LIN@MC.LCS.MIT.EDU>
          I haven't been.  Parnas hasn't been.  Who has been?  
          I would not blame people if they did however.  Big things are
          more complex than little things.

    By far the most common measure of complexity that has been offered in
    these discussion (whenerver a metric has been provided - often
    complexity is simply claimed), it has been code size.  You made a
    point of that yourself in your Scientific American article (although
    in that context you were concentrating specifically on the software
    complexity issue, so there was no confusion).  

In which case I haven't made the case on the basis of code size.

    almost every
    computer science critic of SDI has concentrated on code to the
    exclusion of other elements..

Pls name ONE.

    Big things (in a
    software complexity sence) are NOT necessarily more complex than
    little things (if the little refers to software and the complexity
    measure is system complexity).  

I suggest you read Boehm's Software Engineering Economics.  He
compares different complexity measures, and concludes that lines of
code is as good a measure of complexity as anything else, and since it
is an easy-to-get number (by comparison), it is useful to use.  But
even he notes that it merely reflects complexity.  *For a given type
of problem*, big things are more complex than small things.  This was
the sense in which I meant my original statement.

        Besides, AEGIS is enormously easier to test.  Remember, it is a
        real-time system.  SDI will have to handle 10^6 potential targets
        in 30 minutes.  AEGIS is designed to keep track of 200 targets
        within ~ a half hour flight time.

    First, an ocean environemnt (or a
    land environment) is FAR more unpredictable than a space environment.

AEGIS doesn't scan the ocean; it scans the volume of space above it.  

    But the projectile numbers
    are a bit misleading.  First, Aegis is covering a limited zone.  If
    the SDI system was set up in a similar zone pattern, the number of
    projectiles per subsystem would drop accordingly.

But the subsystems would have to be integrated.  

    An ocean environment is bound to generate more false signals (birds,
    etc...)  from nature than a space environment.

But the ocean evnironment is better understood than space.

------------------------------

Date: Sat, 11 Jan 86 10:09:43 EST
From: Herb Lin <LIN@MC.LCS.MIT.EDU>
Subject:  Summing up on SDI


    From: Jim McGrath <J.JPM at Epic>

    So the real question
    is whether it can protect cities.

    I would tend to doubt it, under a full and unimpeded Soviet attack.
    But there are many scenarios (from accidental launch to a limited
    (decapitation or counterforce) strike to a second strike (the first
    perhaps going to Europe and/or China)) where it quite possibly could.

This is the nub of my objection to SDI.  ALL of the limited goals that
proponents envision can be accomplished at lower cost, faster, and
with less technical risk with other programs.  The one grand goal that
other programs cannot accomplish, SDI can't either.

No matter what goal you give it, SDI isn't the way to go.

------------------------------

End of Arms-Discussion Digest
*****************************