Tuttle & Paige (again)

Tuttle & Paige (again)

[Introspect Technologies]

Just a few thoughts on Admiral Tuttle's remarks.  (Sorry for dragging this
discussion out, but I haven't had time to respond before now and it's
difficult to let some of these outrageous remarks pass unchallenged.)
I don't know Admiral Tuttle's or Secretary Paige's e-mail addresses. I'd
appreciate some help in getting these comments to them.  Ralph at ASA
should probably get a copy also.  Thanks in advance.
-------------------------------------------------------------------------

>We should reexamine our software policies and standards with a view toward
>removal of impediments to the use of the best current industrial tools and
>practices.  DOD is no longer a dominant market force in driving languages
>and software standards -- and we need ongoing means for adopting the best
>commercial standards available.

There is a lot of talk these days in DoD about adopting "best commercial
practices".  Unfortunately, I haven't encountered anyone who can define
what they are.  Are they the practices that routinely cause commercial
products to be years late and millions over budget?  Are they the ones
that caused phone service to crash for the entire Eastern US last year?
The list of commercial failures is long but the point is that commercial
developers really don't have any better methods for building software than
DoD; in many cases they're worse.  But some in DoD see a Silver Bullet
and are going after it.

>Techniques such as object-oriented design
>and programming and support for distributed computing and massively parallel
>processors are supported through industry-standard languages.  Our single
>chosen language, ADA has not evolved, and cannot evolve rapidly enough to
>provide timely access to the best new methods.
>
>Object-oriented methods have proven effective for development oflarge
>industrial applications and have features well suited to our goal of
>software reuse.  We are already employing networks of distributed computers,
>and the next generation desktop machines will almost certainly be massively
>parallel  processors.  ADA does not effectively support object-oriented
>programming -- distributed computing -- and massively parallel processors
>now -- and ADA 9X will not provide many capabilities already widely
>available through C++ and parallel implementations of C.

Object-oriented programming and distributed computing are two separate
subjects and their juxtaposition in the sentence above is confusing.  When
Ada 9X becomes official in a year or so, it will support OOP as well as
C++ by any objective measure.  (And I have no doubt that the major vendors
will be ready to ship their compilers on the day 9X is adopted as a
standard.)  As for distributed/parallel, there is no technical reason for
the lack of parallel Ada.  Typically, Ada has not been considered a
research language.  Consequently, parallel processors have emerged from
their research labs with derivatives of cheap, simple languages.  (As much
as I dislike GregA's strident tone, he nailed this topic: (D)ARPA spends
megabucks per year subsidizing the development of, e.g., Connection
Machine but doesn't levy any requirements for developing parallel extensions
to Ada.)

I wish the Admiral had been a little more specific about what features he
feels 9X won't support.  Where was he when the Ada community was expressing
its needs and determining the requirements for the language revision?

Side question for Admiral T and his advisors: C++ is currently undergoing
ANSI standardization which will put it on the same ten-year revision cycle
as Ada.  Does this mean that C++ won't change fast enough and we'll have
to move to, say, Visual Basic++?


>We must facilitate access for system developers to COTS computing languages
>that effectively support both object-oriented programming and massively
>parallel processing.   We must modernize our current antiquated software
>specification procedures to permit -- even mandate -- the best automated
>methods available.

What are these "best automated methods"?  I smell vaporware and several
million dollars in Navy research projects.  This will be a real tragedy
if the Admiral and his advisors really believe that this stuff is available.


>I have recently signed our correspondence to Emmett Paige, our new Assistant
>Secretary of Defense for C3I, recommending development of a new strategy for
>accommodation of new software practices in a timely manner and relaxing
>adherence to policies originally adopted to enforce good practice that have
>now become an anchor.
>
>I propose in that correspondence to address process models -- design tools
>-- languages and documentation standards in an entirely new manner akin to
>the way we now handle hardware, rather than through the glacial revision
>process for our outmoded software documentation procedures and languages.

I am very sympathetic to the idea of streamlined documentation standards.
I should also point out that there is no language better suited to support
a hardware-like approach to software development than Ada.


>I have volunteered to take the lead in this adventure.  Included in this
>strategy should be measures to encourage the use of fourth generation
>computer languages better suited than ADA and others of the third generation
>to problem-oriented programming.  Explicit language features directed toward
>timing -- security policy and task priority should be included -- as well as
>generous  support  for  programming in new, diverse parallel and distributed
>computing architectures.
>
>Secondly, I have recommended to the Chief of Naval Research a focus in the
>computer technology techbase on technologies directed toward specifying and
>producing correct, supportable and timely software.  As most costly software
>faults are introduced during specification and early design, I have selected
>this phase of development for special early emphasis.
>
>My highest priorities are the following: Formal methods for software
>specification -- Formal methods for parallel and distributed computation --
>and specification - Driven prototyping methods.  ONR's level of support for
>software basic research in these areas is adequate; however, exploratory
>development is marginal and advanced development is inadequate to meet our
>needs.
>
>Once available, these specification languages -- automated verification
>tools -- and advanced prototyping techniques must be made available to
>software developers.  These new methods and the COTS software that supports
>them must be fully supported in policy and procedure.
>

More R&D.  When will all these new 4GLs be available?  Five years?  Ten?


>The matter of formal methods for requirements generation and software
>specification merits special attention.  Increasingly in our systems
>assurance is the watchword.  In mission planning, for example -- with the
>diversity and sensitivity of many of our surveillance -- reconnaissance --
>and intelligence resources, multilevel security is essential.  In achieving
>true trusted software at the B3 and higher levels that are necessary in this
>process, very strict, formal software design rules must be followed.  Formal
>methods technology is the keystone to achieving this level of assurance.

When do you expect Microsoft and Borland to start shipping B3 software?
Do you believe that you can achieve trusted software levels with C and
C++?  This seems an incredible contradiction to what came before.  I even
agree that formal methods are important but this runs against the grain of
the very people you are trying to appease by eliminating the Ada mandate:
much, if not most, of the resistance to Ada (IMHO) is because programmers
resent restrictions such as strong typing.  (Insert favorite anecdote here:
I was debating the relative merits of Ada and C with a rather talented
programmer and I asked the question, "Wouldn't you rather have the compiler
find your mistakes instead of tracking them down with the debugger?"  His
reply: "I don't make mistakes."  And he was perfectly SERIOUS! :-)  In my
experience, it is incongruous to push for formal methods on the one hand
while pushing for unstructured languages on the other.


>A second example may be even more compelling from a standpoint of cost and
>system performance.  The combat system community has not migrated rapidly to
>COTS and to our series of tactical advanced computers -- nor has it been
>willing to connect its systems interactively with C3I systems.  The levels
>of assurance required in weapon systems are so demanding that they have
>dwelt in a self-contained system design and operational environment.  Now
>that commercial hardware has advanced to the point that it should meet their
>needs for survivability, formal software methods can bring them the degree
>of confidence in system  reliability  and performance assurance needed to
>bring them fully into an open-system environment -- both in design and in
>operational integration with C3 systems.  This paradigm shift would result
>in a major cost-saver and performance enhancer for Navy.

If this paragraph is meant to say that using COTS is cost-effective
compared to writing everything from scratch, then congratulations, you
have discovered the obvious.  There are two points that need to be made,
however.  First, Ada is not an impediment to the use of COTS.  Bindings
and interfaces exist to databases, networking/IPC products, GUI builders,
you name it.  Secondly, assume that you have a million-line project
(moderate by today's standards).  Also assume that you have achieved 80%
of that thru COTS, GOTS and reuse.  That still leaves you with 200,000
lines of code to develop.  Do you really want 200,000 lines in some
combination of C, C++ and proprietary 4GLs?  Has the maintenance nightmare
that led to the development of Ada already been forgotten?


>Thirdly, I have established a quality management board to address the
>software development process from top to bottom.  This board, comprising
>member of my staff, the Navy Laboratories, the Academic World and
>Software-Oriented Industrial Activities such as the Software Productivity
>Consortium and the Software  Engineering  Institute, has begun already to
>bring  about  a  new  strategy for military software development that I will
>volunteer to DOD as the backbone of a new DOD-wide strategy.

Why do you need to study this subject?  If commercial practices are so
good and well established, why don't you just push to adopt them as they
are?  (The obvious answer to my rhetorical questions is that they don't
exist, that the commercial world is in no better shape than the DoD.)  How
long will your QMB study the issue?  How long after they study it will it
take to change how DoD does software?


>A year  ago my irrepressible chief scientist showed you a slick viewgraph of
>a  sleek -- streamlined -- hand-crafted Duesenberg -- complete with mahogany
>trim and 50 coats of hand-rubbed lacquer -- the product of a coachwork
>artist.  The  caption said "This is your brain".  He put beside it a grainy
>black-and white photo of a model-T with the caption "This is your brain on
>ADA".   The point was that in order to make software affordable -- reliable
>-- reproducible we were forced to design and configuration control processes
>that limited performance and acceptability much as the Model-T was limited
>by 1920s-era assembly-line technology.

It's funny that your ICS should use automobiles as a metaphor for computer
languages; I've often thought of C and Ada as cars.  C is a 1970s VW Beetle:
compact, efficient, widely available and popular.  Ada is a 1990s Sport
Utility Vehicle: made to handle rough terrain and heavy loads.  C++ failed
(IMHO) because it tried to beef up C without addressing its fundamental
weaknesses (e.g., no implicit library system, no tasking model, still can't
tell the difference between an array, a pointer and an address).  In our
car analogy, C++ is like a Beetle with a V-8 engine.  (This is not intended
to start a flame war: I really don't care what C people think of Ada and
I suspect the feeling is mutual. :-)  The real question is, are you in
favor of abandoning a language that can do the job just because it isn't as
popular as some other language(s)?  If so, are you willing to pay the
additional maintenance costs down the road?


>Ladies and gentlemen, the software revolution is upon us.  If we deal
>successfully with the software technology challenge, we'll have the
>performance of a Dusenberg at the cost and reproducibility of a Model-T --
>the Twenty-First Century Lexus.  Thank you for your kind attention.

Overall, I think the Admiral and his advisors are confused about the whole
Open Systems concept.  Open systems isn't about custom software;  open
systems means you settle for whatever you can get--it may be obsolete but
at least its standard.  (Insert Open Systems anecdote here:

        Admiral Tuttle to staff: "Build me an aircraft carrier."
        Staff: "Yes sir!"
        (time elapses)
        Staff: "Sir, aircraft carriers are kind of expensive, but we do
                have quite a few spare submarine parts around."
        Admiral Tuttle: "OK, build me one of those."
        Staff (sheepishly): "Sir, the parts are vintage 1970 so it
                won't exactly be state-of-the-art."
        Admiral Tuttle: "Well, if that's all that's available, maybe
                we should re-examine our mission requirements."

        SURE

:-)  If you want a Lexus you still have to pay Lexus prices.

The Admiral's goals are bold, noble and lofty.  Unfortunately, there are
too many overtones of empire-building and a bunch of consultants who have
never had to maintain someone else's code snooping around for research
dollars.

The biggest problem I have with this whole address is that Ada was even
mentioned in it.  The Admiral (or whoever actually wrote it) seemed to
want to say that the DoD's software development process is broken (which
it is, but no more than the prevailing commercial practice).  Yet, Ada
is often brought in to take the blame.  This is a /non-sequitur/ of the
highest order.  Ada may not me the solution to all of the DoD's software
problems, but it is certainly not the problem.

=============

>Emmett Paige (Assistant Secretart of Defense for C3I) replied to the
>issues raised by Admiral Tuttle:
>
>"ADA IS NOT DEAD ADA IS ALIVE, DOING WELL, AND STILL NEEDED AS MUCH AS
>EVER DESPITE THE VIEWS OF SOME SENIOR FOLKS ON THE INTERVIEW AND SPEAKING
>CIRCUIT.
>
>PLEASE TELL ME WHAT I MUST DO TO GET THE SHOW ON THE ROAD AND REJUVENATE
>THE ADA EFFORT, TO INCLUDE OPENING UP THE RE-USE REPOSITORIES TO INDUSTRY
>AND ACADEMIA WITHOUT ANY INHIBITIONS.  WE MUST OPEN THE GATES IF WE ARE
>TO BE SUCCESSFUL IN ENCOURAGING USE OF ADA IN THE PRIVATE SECTOR."
>
>SIGNED:  E.PAIGE JR

My humble suggestions (just a few off the top of my head):

=> Get ARPA and other DoD/government research organizations in line.  If
they spend millions of (my!) taxpayer dollars to develop new hardware,
make sure some of the money is earmarked for development of Ada tools
and bindings.  Give preference to research projects that specify Ada.

=> Support industry standards organizations by sending government
representatives to working groups and committees.  Many of these working
groups are dominated by the C/C++ clan so the standards that result tend
to be C-specific.  Not only are general-purpose languages like Ada and
Modula getting shafted, many niche languages (e.g., Lisp, APL, Forth) are
entering the endangered languages list.  This is a potentially tragic
situation where C could squash much of our programming heritage.  ALL WE
WANT IS A LEVEL PLAYING FIELD.

=> Audit mandate compliance.  I was shocked when Major Croak announced
at last year's Tri-Ada that he hadn't approved any Ada waivers.  Maybe
Ada was being used on the F-22, but I could see many projects, new
development and migrations, that weren't using Ada.  The mandate is being
widely ignored and people at the General and Secretary level must either
commit to the mandate 100% or remove it.  The hypocrisy of the current
situation should not be allowed to continue.

=> Survey user needs regarding COTS products.  Commercial tool vendors
will provide Ada bindings and interfaces if they smell $$$.  The problem
is that a sales rep in one part of the country may only have one Ada
customer.  Consequently, he won't push for Ada.  The solution is to get
all the Ada customers together and show that there is enough of a demand
nationally to justify puting out the new product extensions.

=> Push the MIS aspects of Ada.  Chris Anderson and the 9X team have done
an excellent job (IMHO) of positioning 9X for MIS applications.


(BTW, thanks for asking.  Things will get better if you keep asking and
listening. :-)

========

Douglas Arndt, CDP
Introspect Technologies, Inc.
PO Box 1135
Colorado Springs, CO  80901-1135
(719) 634-5744
intros@cscns.com

---------------------------------------------------------------------------
        Maybe these views are the same as my company's, maybe not.
///////////////////////////////////////////////////////////////////////////
---------------------------------------------------------------------------
                              "The life of an Ada coder is always intense."
                                             -- Repo Man (with apologies:-)
---------------------------------------------------------------------------