From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on
	ip-172-31-74-118.ec2.internal
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.5-pre1
Date: 24 May 93 19:58:10 GMT
From: dog.ee.lbl.gov!overload.lbl.gov!agate!howland.reston.ans.net!zaphod.mps.o
hio-state.edu!sol.ctr.columbia.edu!The-Star.honeywell.com!saifr00.cfsat.honeywe
ll.com!shanks@ucbvax.Berkeley.EDU  (Mark Shanks)
Subject: Re: Hey, blame the private sector!
Message-ID: <1993May24.195810.796@saifr00.cfsat.honeywell.com>
List-Id: <comp.lang.ada>

In article <1993May24.183623.22527@mlb.semi.harris.com> smccoy@dr3w.ess.harris.
com (Scott McCoy) writes:
>I put the 'Ada question' to Mr Strassman recently, and his response (I
>paraphrase) was that while Ada was a good technology, technology alone 
>will not solve the DoD's software development problems.  Mr Strassman 
>felt that the keys to getting this problem under control involved
>process definition and performing solid functional economic analysis
>as the basis for information systems development.
>
>His point was that when you develop 25 systems that fill the *same*
>function, then it doesn't really matter what language/technology/
>mystical incantations you use to develop them, does it?   You're 
>wasting time and money.
>
>So I think that it is more accurate to characterize his feelings
>towards the Ada question as "that's not the issue, stupid", as opposed 
>to embarassment.
>
Well, now I'm REALLY confused. Why does Mr. Strassman espouse process
definition as a key to solving DoD software development problems but
minimalize the useage of the common (mandated) language (and its associated
processes, e.g., compilers, debuggers, etc.) as another consideration
in solving the perceived problem? I am puzzled by your choice of
words ("mystical incantations" "wasting time and money" and "that's
not the issue, stupid" (stupid!!?)) in the context of any, never
mind only DoD, software development and language consideration.

I have a few years experience in software development at McDonnell
in St. Louis, and I will be the first to agree that (IMHO) Mac at
least could stand some improvement in process definition, but this
isn't information systems development but avionics systems. If Mr.
Strassman's objective is to allow (or, OK, FORCE) the contractors
to develop defined processes, I think that is a Good Thing. But if,
as I suspect, the goal is to present some sort of mandated processes
to the contractors as a fait accompli, well, I don't think that will
help the problem at all. How on earth did we get to the point of
developing 25 systems that fill the *same* function, anyway?

If Ada/language isn't THE problem with DoD software development, I can't
help but to think it's a component of the problem. And I don't think 
that Greg (or most of the posters here) think that Ada qua Ada is 
A Problem, but that the DoD's handling of it IS, and your paraphrasing
of Mr. Strassman's responses sounds as though he would rather talk 
about anything BUT Ada and the DoD.

-------------------------------------------------------------------
| Mark Shanks                          |           
| Principal Engineer                   |    All opinions mine,  
| 777 Displays                         |        of course.
| shanks@saifr00.cfsat.honeywell.com   |          
| "We have such sights to show you..." |            
-------------------------------------------------------------------