Re: Hey, blame the private sector!

[dog.ee.lbl.gov!overload.lbl.gov!agate!howland.reston.ans.net!darwin.sura. net!source.asset.com!vand@ucbvax.Berkeley.EDU (Laurence VanDolsen)]

In article <1993May24.195810.796@saifr00.cfsat.honeywell.com> shanks@saifr00.cf
sat.honeywell.com (Mark Shanks) writes:
>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.
>
 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.

I cannot speak for Mr. Strassman.  The main thrust of current thinking
in the DoD, as evidenced by keynote addresses at various conferences and
other indications, seems to be that process maturity is a high payoff
area of concentration. (I happen to agree.)  Further, there seems to be
a consensus that Ada, more than most other languages, tends to be
supportive of disciplined process.  There seems to be a growing
recognition that the Mandate has outlived its usefulness.  There does
not seem to be a strong push to rescind it so much as to remind
everybody that it has a built-in provision for chossing a non-Ada
approach.  "All ya gotta do" is show that the use of some other language
will have cost and risk advantages over Ada.  Critics howl that nobody
has ever had to prove the cost-effectivenes of Ada, and they are right,
but who ever said life was fair?

There is a tendency, often seen on the net, to take any statement by any
single Govt. representative as being a very significant indicator of DoD
direction.  We must remember that the DoD is not an effective
dictatorship.  People have, and enunciate, a broad range of opinions.
Which of these turns out to be significant is usually not known for
several years after the fact, when the statements can be viewed in
historical perspective.

Currently, the DoD is funding STARS, the SEI, AJPO, and various reuse
and reengineering initiatives.  These actions are indicative of a
consensus that cost-effective development of reliable software will
benefit from disciplined process and institutionalized reuse, and that a
significant proportion of future software dollars are going to continue
to be tied up in the support of legacy programs.  In all of these areas,
there is a general consensus, but not unanimity, that Ada is the
language of choice for the development of robust systems with minimal
life-cycle support costs.

We got into the habit of building new systems instead of adapting old
ones because:

	It is more fun to start from scratch

	Old systems were very difficult to understand well enough to
	adapt

	Technology support for reengineering and platform portability
	did not support cost-effective reuse

	There were few effective communication mechanisms whereby
	program managers could become aware of reusable assets.

	There were (are) 'territorial imperatives' which make it
	difficult for a program manager to adopt and use something
	from another service, or even another branch of the same service.

The STARS program emphasis on Megaprogramming, and the ASSET, CARDS,
ASR, and other reuse libraires and related support services are all part
of a DoD effort to end-run these difficulties.  We can argue about the
implementation approaches, but I think we can agree that the general
direction in which the DoD is moving is the correct one.