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=-0.0 required=3.0 tests=BAYES_40 autolearn=ham autolearn_force=no version=3.4.5-pre1 Date: 25 May 93 16:11:25 GMT From: dog.ee.lbl.gov!overload.lbl.gov!agate!howland.reston.ans.net!darwin.sura. net!source.asset.com!vand@ucbvax.Berkeley.EDU (Laurence VanDolsen) Subject: Re: Hey, blame the private sector! Message-ID: <1993May25.161125.21879@source.asset.com> List-Id: 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.