Ada - DoD HOLWG, Col Wm Whitaker, 1993

BEYOND THE LANGUAGE
The purpose of the project was to reduce the cost of DoD software, not to build one more language. Reuse was the major thrust driving the imposition of a common language on the DoD. If only the technical features of the language were important, the DoD should have been as well served by 100 good languages. But commonality holds no profit unless it is put to advantage.

There are three aspects of the use of Ada, each important in its potential for cost reduction.

The first is the technical capability of the language:

The second is commonality:

The third is reuse:

Throughout the project there was the expectation, explicitly promised and budgeted for, that the government would develop, control, and provide certain basic tools and applications packages. These included the first level of software tools: compilers, editors, program analyzers, testing aids, etc. There was never the intent that all such capabilities were to be furnished by the government; as the above discussion on compilers points out, one expected that commercial offerings would eventually be superior to the basic level common set. Nevertheless, we viewed it as the responsibility of the project, or of the accompanying Service programs, to get things started. While still in the AJPO budget in late 1981, this never was accomplished. In addition, we had planned that libraries of reusable code specific for particular applications areas would be maintained by organizations knowledgeable in the area. (We use the term "library" or "toolbox" but that sends the wrong message. A library is a collection of things that are available. What we need is a concept of a bunch of parts that are necessary and sufficient and are put together and polished and improved over the years.)

As far as I know, there was no single decision to abandon these goals, but I have my suspicions as to the how it happened. The DoD management had found that single point promises of universal capabilities were unreliable, be it the capability a single aircraft design for all Services, or a single compiler; competition was the solution. The validity of this position had certainly been established by experience, the latest being the discouraging results of the highly touted ALS and AIE compiler/environment contracts. These had each been sold by the sponsoring Service as a complete capability efficiently produced. The results could have only reinforced the distrust of the Deputy Secretary of Defense, William Howard Taft IV, for such a solution, and his favor towards letting industry handle the situation, unfettered by government interference. I sense this as the prevailing philosophy. Although there was no explicit hindrance to the follow-on programs, indeed they were approved, it turned out that they could be accomplished only with extraordinary support at the OSD level. The language development had this support and succeeded; the tools effort did not, and languished.

I do not mean this speculation as a criticism of the OSD philosophy, in fact, I support it and agree with it in detail, as my vindicated expectations for the Ada compiler industry show. But I wanted to make a small exception in this case. The idea was that the government should sponsor a starter set of tools, which would not be exclusive, to show the way, and then stand aside and let industry refine and continue. The thought was that the government had sufficient experience to know what was immediately required, but should not expect to dictate future developments. This is a concept that one could sell at an instant, but one which did not have staying power in the face of other demands.

Nevertheless, while recognizing the predilection against this mode, I pursued the dream. I got involved with two other joint programs, in 1982 and in 1986, both run by Colonel Joseph S. Greene, with whom I had worked at Kirtland AFB. The World Wide Military Command and Control System (WWMCCS) Information System (WIS) was a joint project to modernize the nation's strategic command and control capability. Greene and I were responsible for advanced technology on this program and believed that the right software technology for the extraordinary demands of this system was Ada, a bold position in 1982. Supported by a number of investigations and demonstrations, the WIS Joint Program Management Office selected Ada as its implementation language in May 1983. In June, perhaps influenced by this commitment, Richard DeLauer, then Under Secretary of Defense for Research and Engineering, sent out a memo [DeLauer, 1983] to all Services and Agencies mandating Ada for future DoD mission critical systems, directing that

"The Ada programming language shall become the single common programming language for Defense mission-critical applications. Effective 1 January 1984 for programs entering Advanced Development and 1 July 1984 for programs entering Full-Scale Engineering Development, Ada shall be the programming language."

In support of this view, WIS let 54 Ada contracts, known as the NOSC tools, since procurement was done by the Naval Ocean Systems Center. The purpose of these was to prove that the state-of-the-practice would support Ada systems developments. These contracts exercised the state-of-the-practice among DoD contractors and evaluated available compilers, training, management capabilities, all that goes into a system development. The large number of contracts meant that one could determine if Ada was ready, not just whether a single contractor was capable. It was quite permissible for some contracts to fail, they often do even with mature technologies. The success of a large number was sufficient to establish the viability of Ada. Along the way, a number of tools were developed and made publicly available, for WIS and for any other Ada development, primarily by being submitted to an Ada repository. Rick Conn of General Electric was chiefly responsible for promoting this pioneering component library of Ada source code set up on a machine (SIMTEL20) at White Sands Missile Range, NM, accessible over the ARPANET. WIS was also concerned with, and funded, the bindings of Ada programs to exterior standards, such as the Graphical Kernel System (GKS) and database systems, without which systems could not port, even with portable code.

We expected that the technology work would be continued by the WIS prime contractor, the tools would be refined, and a machine independent environment set of high quality components would ensue. Machine independence was to be the key to settling the hardware predicament of this system. Managerial and contractual circumstances negated this plan and little additional component work was forthcoming.

In 1986 Col. Greene became the Director of the DoD Software Technology for Adaptable Reliable Systems (STARS). I had served my 30 years and was retired from the Air Force so could only participate as a supporter from the sidelines, but maintained a keen interest. STARS was part of a three pronged "Software Initiative", the other two being the AJPO and the Software Engineering Institute (SEI) in Pittsburgh. Again, contractual constraints shaped the program. Initially there were a number of "STARS Foundations" contracts, in the line of the NOSC Tools, this time chiefly through the Naval Research Laboratory (NRL). The main program consisted of three prime contractors who were supposed to integrate and exercise environment technologies. The contracts specifically required 60% of the effort to be done by subcontractors, in order to stimulate innovation. Again development of a repository was a major feature of the program. Once again, managerial and budgetary constraints conspired against our expectations.

Another early try was the Common Ada Missile Packages (CAMP) program at AFATL, which was the first large government effort to develop a specific applications library. This was managed by Christine Anderson, who became the director of the Ada 9X program. CAMP was contracted for in the normal government fashion, from a single contractor. It might have been more Ada-like if it were open and funded for continued polishing and extension. The moral of all these efforts is that it is vital that components be supported and polished, and subject to continual peer review.

EXPECTATIONS

Realized

Ada, the project and the language, was driven by the goal of encouraging good software design and programming practice. The modularity provided by packages and the separation of specifications and bodies is exceptionally useful in this regard. Properly managed, it is applicable to all levels of the design process, as well as to the programming task. Ada itself is used as a program design language [IEEE, 1987], and its use has spawned general interest in design languages. Used in design, Ada allows designs to be compiled, and even mock executed, rigorously verifying critical interfaces at a point in the process where adjustments are convenient. Ada facilitates the effective direction of a development effort involving hundreds of people, even in different organizations, and the controlled maintenance and modification of software over many years. It does the technical job that was required.

Ada was designed to support and encourage "object-oriented design", and it does. Ada packages can be used to create "objects". In the 70's there were some very vocal objections that Ada did not have "abstract data types" (the buzzword of the day), since a package was not limited to someone's notion of what that meant. During the 80's the use of the "object-oriented" buzzword has changed; one now implies "object-oriented programming" features such as "inheritance", which even be dangerous in high-integrity systems. Ada 9X will provide this support in order to promote programmer acceptance, but this addition neither enhances the system engineering capability of Ada nor disparages the original design.

Ada has achieved a level of acceptance beyond what was required, a level that we had hoped for. It is an ANSI and ISO standard, as well as a military standard. It is mandated, not only by the DoD, but by the Congress. It is used by many other large organizations. This was the goal of the project and it succeeded.

Ada had to satisfy a large set of requirements. One of the dangers was that a poor design would result in a language that was too large or too complicated to be useful for the DoD. There is no agreed to quantitative measure for computer languages, but I could argue that Ada is smaller than COBOL, and not enormously larger than FORTRAN. The text of a good Ada program is extremely readable. These properties combine to make Ada very teachable to DoD programmers.

The educational aspects of Ada are the most bewildering. It is being taught in a fairly large number of institutions, from high schools on up, but, while growing, it has certainly not become the principal language of choice. I have had excellent results teaching Ada to brand new Airmen with a high school diploma and 11 weeks in the Air Force [Whitaker, 1983]. But there are institutions where it has been proclaimed too difficult to introduce below graduate Computer Science. It might be fair to say that Ada is a language for software engineering, rather than just "programming", and that discipline is very young.

Denied

Tools for and in Ada are now widely available, but it is my greatest disappointment that there are not more and better tools publicly available for Ada than for all other languages combined. There was much effort and many opinions on how to integrate tools but few new ideas for tools beyond those in general use. I had expected that Ada would have lots of facilities because we could now have them machine independent. I tried to do a bit, pick up the slack, prime the pump and get people interested, but not very successfully. WIS made starts on such simple things as math packages, a copy of the UNIX tools, an I/O generalization (from simple terminal to windows), communications capabilities, graphics, etc. We could exert influence, but it was administratively impossible to actually command a bunch of programmers to do such tools. Beyond Ada programming tools, I wanted to use Ada to introduce and support other standards efforts for the DoD, such as the Standard Generalized Markup Language (SGML) and the Computer Graphics Metafile (CGM) which are now being used by the DoD Computer Aided Logistics System (CALS). Maybe I was wrong and the world would not have been better off, but I doubt it. 9X reiterates the promises to release tools into the public domain. I hope this finally takes off.

There are a lot of things that one can do differently because there is a truly common language. Ada provides a lingua franca for communication beyond programming. Pure Ada is used as a design language, a command language, database entry and checking, and for message format definition, resulting in enormous benefits in development time and system reliability. But much of the applications are of conventional design and have not exploited the full range of novel Ada techniques.

Educationally, Ada has been beset with two unique obstacles, neither technical. There is a feeling that Ada facilitates all those aspects of good design and management that one puts under the umbrella term of "software engineering", and it certainly does. Some managers have taken this to the extreme and decided that there is no point in using Ada unless they can train their personnel to a total "software engineering" capability. While admirable, this is difficult, and possibly undefined, so the result is delay, intentional or not.

The other obstacle, which affects especially the academic world, is that good Ada compilers were initially expensive relative to some other languages. While the academic price of Ada compilers is now competitive and the computer resources required are available in present desktop computers, the requirements may exceed (mostly in memory) those purchased some time ago. It is certainly true that such constraints are not limited to the academic community, but I note the example of the US Air Force Academy teaching ALGOL for years to cadets because Burroughs gave them a machine effectively supporting only ALGOL, in spite of the fact that ALGOL was not used elsewhere by the Air Force. I protested this at the time. In 1992 the Military Academies still do not teach Ada as their primary language!

Both the tools and the compiler availability situations illustrate the limits on a US Government program, because it is a government program. The absolute amount of money that could be involved in producing all the tools one could imagine and providing a free compiler for every computer in the country is trivial compared to what the DoD spends on software every month. (In the past, large corporations have had much more freedom for such initiatives, but are facing stricter controls.) However, any such direct government program would be contrary to law and the US economic system, and I would not wish it otherwise. Perhaps the question is whether the government should provide a competitive environment for its internal use.

Ada planned for training, and the expected commercial courses and books became available. A large Ada training problem was instructors that had to show off by making it seem as difficult as possible in order to snow the students. There were even groups that did not want to make the transition to Ada and used training as a delaying tactic. Some suggested that programmers have to know every feature in order to begin (but this is not the way anyone approached any other language), and that they had to have a 3-month training course before they could proceed (although they had no training program for their present languages). Furthermore, they could not use Ada without lots of training in software engineering (although they were accepting the government's billions without apparently any knowledge of, and certainly no training in, software engineering). While all of these preparations are important, they should be important for software development in any language, but they have been used as disingenuous excuses not to use Ada.

PREVIOUS PAGE CONTENTS NEXT PAGE