National Research Council: Ada & Beyond
[Contents] [Part 1] [Part 2] [Part 3] [Part 4] [Part 5] [Part 6]

Ada and Beyond
Software Policies
for the Department
of Defense

Committee on the Past and Present Contexts for the Use of Ada in the
Department of Defense

Computer Science and Telecommunications Board

Commission on Physical Sciences, Mathematics, and Applications

National Research Council

Washington, D.C. 1997

NOTICE: The project that is the subject of this report was approved by the Governing Board of the National Research Council, whose members are drawn from the councils of the National Academy of Sciences, the National Academy of Engineering, and the Institute of Medicine. The members of the committee responsible for the report were chosen for their special competences and with regard for appropriate balance.

This report has been reviewed by a group other than the authors according to procedures approved by a Report Review Committee consisting of members of the National Academy of Sciences, the National Academy of Engineering, and the Institute of Medicine.

The National Academy of Sciences is a private, nonprofit, self-perpetuating society of distinguished scholars engaged in scientific and engineering research, dedicated to the furtherance of science and technology and to their use for the general welfare. Upon the authority of the charter granted to it by the Congress in 1863, the Academy has a mandate that requires it to advise the federal government on scientific and technical matters. Dr. Bruce Alberts is president of the National Academy of Sciences.

The National Academy of Engineering was established in 1964, under the charter of the National Academy of Sciences, as a parallel organization of outstanding engineers. It is autonomous in its administration and in the selection of its members, sharing with the National Academy of Sciences the responsibility for advising the federal government. The National Academy of Engineering also sponsors engineering programs aimed at meeting national needs, encourages education and research, and recognizes the superior achievements of engineers. Dr. William A. Wulf is interim president of the National Academy of Engineering.

The Institute of Medicine was established in 1970 by the National Academy of Sciences to secure the services of eminent members of appropriate professions in the examination of policy matters pertaining to the health of the public. The Institute acts under the responsibility given to the National Academy of Sciences by its congressional charter to be an adviser to the federal government and, upon its own initiative, to identify issues of medical care, research, and education. Dr. Kenneth I. Shine is president of the Institute of Medicine.

The National Research Council was organized by the National Academy of Sciences in 1916 to associate the broad community of science and technology with the Academy's purposes of furthering knowledge and advising the federal government. Functioning in accordance with general policies determined by the Academy, the Council has become the principal operating agency of both the National Academy of Sciences and the National Academy of Engineering in providing services to the government, the public, and the scientific and engineering communities. The Council is administered jointly by both Academies and the Institute of Medicine. Dr. Bruce Alberts and Dr. William A. Wulf are chairman and interim vice chairman, respectively, of the National Research Council.

Support for this project was provided by the Department of Defense (under contract number DASWO 1-96- C0028). The views, options, and findings contained in this report are those of the authors and should not be construed as an official Department of Defense position, policy, or decision, unless so designated by other official documentation.

Library of Congress Catalog Card Number 96-71960
International Standard Book Number 0-309-05597-0

Additional copies of this report are available from:

National Academy Press
2101 Constitution Avenue, NW
Box 285
Washington, DC 20055
202/334-3313 (in the Washington Metropolitan Area)

Copyright 1997 by the National Academy of Sciences. All rights reserved.

Printed in the United States of America


BARRY BOEHM, University of Southern California, Chair
THEODORE BAKER, Florida State University
WESLEY EMBRY, Silicon Graphics Inc.
JOSEPH FOX, Template Software
PAUL HILFINGER, University of California at Berkeley
MARETTA HOLDEN, Boeing Corporation
J. ELIOT B. MOSS, University of Massachusetts at Amherst
WALKER ROYCE, Rational Software Corporation
WILLIAM SCHERLIS, Carnegie Mellon University
S. TUCKER TAFT, Intermetrics Inc.
RAYFORD VAUGHN, Electronic Data Systems Corporation
ANTHONY WASSERMAN, Interactive Development Environments Inc.

Special Advisor
BARBARA LISKOV, Massachusetts Institute of Technology

PAUL D. SEMENZA, Study Director
GLORIA P. BEMAH, Administrative Assistant



DAVID D. CLARK, Massachusetts Institute of Technology, Chair
FRANCES E. ALLEN, IBM T.J. Watson Research Center
JEFF DOZIER, University of California at Santa Barbara
SUSAN GRAHAM, University of California at Berkeley
JAMES GRAY, Microsoft Corporation
BARBARA GROSZ, Harvard University
PATRICK M. HANRAHAN, Stanford University
JUDITH HEMPEL, Modeling Simulations Inc.
DEBORAH A. JOSEPH, University of Wisconsin
BUTLER W. LAMPSON, Microsoft Corporation
EDWARD D. LAZOWSKA, University of Washington
BARBARA LISKOV, Massachusetts Institute of Technology
JOHN MAJOR, Motorola
ROBERT L. MARTIN, Lucent Technologies
DAVID G. MESSERSCHMITT, University of California at Berkeley
CHARLES L. SEITZ, Myricom Inc.
LESLIE L. VADASZ, Intel Corporation

HERBERT S. LIN, Senior Program Officer
PAUL D. SEMENZA, Program Officer
JERRY R. SHEEHAN, Program Officer
JEAN E. SMITH, Program Associate
JOHN M. GODFREY, Research Associate
LESLIE M. WADE, Research Assistant
GLORIA P. BEMAH, Administrative Assistant
GAIL E. PRITCHARD, Project Assistant



ROBERT J. HERMANN, United Technologies Corporation, Co-chair
W. CARL LINEBERGER, University of Colorado, Co-chair
PETER M. BANKS, Environmental Research Institute of Michigan
LAWRENCE D. BROWN, University of Pennsylvania
RONALD G. DOUGLAS, Texas A&M University
JOHN E. ESTES, University of California at Santa Barbara
L. LOUIS HEGEDUS, Elf Atochem North America Inc.
JOHN E. HOPCROFT, Cornell University
RHONDA J. HUGHES, Bryn Mawr College
SHIRLEY A. JACKSON, U.S. Nuclear Regulatory Commission
KENNETH H. KELLER, University of Minnesota
KENNETH I. KELLERMANN, National Radio Astronomy Observatory
MARGARET G. KIVELSON, University of California at Los Angeles
DANIEL KLEPPNER, Massachusetts Institute of Technology
JOHN KREICK, Sanders, a Lockheed Martin Company
MARSHA I. LESTER, University of Pennsylvania
NICHOLAS P. SAMIOS, Brookhaven National Laboratory
L.E. SCRIVEN, University of Minnesota
SHMUEL WINOGRAD, IBM T.J. Watson Research Center
CHARLES A. ZRAKET, MITRE Corporation (retired)

NORMAN METZGER, Executive Director



It is increasingly important for the Department of Defense (DOD) to implement effective information systems policies and strategies, as future battles will be decided as much in "cyberspace" as in physical space. The use of effective computer programming languages—and more broadly, of software engineering technology and policy designed for optimal support of DOD requirements—is key to DOD's strategy of achieving information dominance for warfighting. For the past two decades, DOD has used programming language policy as a vehicle for obtaining cost-effective, high-performance information systems. However, the process of software development has changed considerably during this period, as has the computer industry itself. These changes have altered the environment in which DOD develops and produces information systems.

It is in this context that Assistant Secretary of Defense (Command, Control, Communications, and Intelligence) Emmett Paige, Jr., requested that the National Research Council's Computer Science and Telecommunications Board (CSTB) review DOD's current programming language policy. Convened by CSTB, the Committee on the Past and Present Contexts for the Use of Ada in the Department of Defense was asked to:

1. Review DOD's original (mid-1970s) goals and strategy for the Ada program; 2. Compare and contrast the past and present environments for DOD software development; and 3. Consider alternatives and propose a refined set of goals, objectives, and approaches better suited to meeting DOD's software needs in the face of ongoing technological change.

Although the committee focused on programming language issues, it also considered them in the context of software architectures, components, and life-cycle processes, consistent with the realization that successful software engineering strategy involves several elements that are at least as important as the programming language component.

Throughout its deliberations, the committee was sensitive to the fact that the issues surrounding Ada and DOD programming language policy have been the source of vigorous debate among DOD


viii Ada and Beyond: Software Policies for the Department of Defense

policymakers, program managers, government contractors, and the software community at large. Thus the committee made a concerted effort to collect a variety of views, and it received numerous briefings, position papers, and analyses from representatives of government agencies, as well as the defense, aerospace, and commercial industries. The committee membership included many different organizational viewpoints and personal experiences; as it reflected the larger community, so also did it engage in vigorous debate during its own deliberations. In the process of reaching conclusions and formulating recommendations, however, the committee agreed on the importance of DOD adopting software policies that better reflect ongoing significant changes in the discipline of software engineering, while retaining the benefits of prior investment and policy decisions.

The committee also understood the desire on all sides to bring closure to a policy debate that has continued for many years. Several briefings to the committee included requests that the committee not suggest further studies on the topic. The committee found these requests compelling and has attempted to frame its recommendations so that they can be acted on directly by DOD policymakers. Thus, for example, in addition to making recommendations in the main text of the report concerning the appropriate scope of and criteria for DOD software policy, the committee found it useful to propose a revised statement of the current policy as embodied in DOD Directive 3405.1. The committee-modified form of the DOD-revised draft (May 15, 1996) of the directive is offered in
Appendix A for consideration as a template for further revision. The committee was aware that DOD has been conducting an effort to revise this policy; indeed, the committee was provided copies of two different draft revisions.

In addition to the individuals and organizations who participated in committee meetings and wrote position papers for the study (listed in Appendix E), the committee would like to acknowledge the numerous anonymous reviewers for their constructive comments on a draft version of this report. The committee would also like to acknowledge the efforts of Assistant Secretary Paige and his staff, including Cynthia Rand and Connie Leonard, for assisting the committee in locating individuals and materials to consult.

Finally, the committee would like to acknowledge the support provided by the Computer Science and Telecommunications Board and staff. Several Board members took an active interest in the project and offered numerous suggestions that helped to strengthen the report. The CSTB staff were instrumental in organizing the committee meetings and coordinating briefings, reviews, and interactions with Board members. In particular, CSTB's administrative assistant, Gloria Bemah, provided excellent administrative support, and its director, Marjory Blumenthal, played a key role in overseeing the study on behalf of the CSTB. Susan Maurizi edited the report under a compressed schedule, and Gail Pritchard and Jean Smith of CSTB assisted in production of the final draft. Finally, Paul Semenza, the study director, worked closely with the committee in every phase of the study.



Growth in the Commercial Software Industry, 8
Obstacles to Broad Adoption of Ada, 8
    Low Commercial Awareness and Limited Sponsorship, 9
    Limited Extent of Academic Instruction in Ada, 9
    Limited Availability of Ada Tools and Compilers, 10
    Assumption That Ada Has to Control Everything, 11
    Need for Ada-compatible Application Programming Interfaces, 11
    Labor Market Forces, 12
DOD Programming Language Policy, 12
    Policy History, 12
    Ada's Place in Current DOD Programming Language Policy, 14
    Implementation of Policy on Waivers, 14
    Importance of Appropriate Expertise, 15
    Level of Applicability, 15
    Implications, 15
DOD Investment Strategy, 16
Summary of Ada Trends, 16
Critical Questions, 17
Notes, 18

Software Engineering Process and Architecture, 19


xAda and Beyond: Software Policies for the Department of Defense

    Economics of Software Engineering, 21
    Reducing the Complexity of Software Products, 21
    Improving Software Processes, 22
    Influence of Software Environments, Tools, and Languages on the Software Engineering Process, 23
Technical Evaluation of Ada 95 and Other Third-Generation Programming Languages, 24
Available Comparisons of Ada 83 and Other Third-Generation Programming Languages, 26
    Analyses of Language Features, 26
    Comparisons of Empirical Data, 26
    Anecdotal Experience from Projects, 30
The Need to Institute Collection of Data for Software Metrics, 30
Notes, 32

Policy Objectives and Criteria Relevant to Meeting Them, 35
    Relating Criteria to Objectives, 35
    Critical Criteria in DOD's Selection of a Programming Language, 35
    Warfighting and Commercially Dominated Applications, 36
Ada Business-Case Analysis, 37
    Criteria for Evaluation of Ada, 37
    Conclusions, 40
Findings and Recommendations, 42
    Ada Competitive Advantage, 42
    Applicability of Policy to DOD Domains, 42
    Scope of Policy, 43
    Policy Implementation, 43
    Investment in Ada, 43
    Software Metrics Data, 44
Assessment of Policy Alternatives, 44
    Conditions for Requiring Ada, 44
    Ada Requirement, 47
    Language Choice Process, 48
    Investment in Ada Infrastructure, 49
Economic Analysis of Investment in Ada Infrastructure, 50
Notes, 52

Recommended Policy for Choice of Programming Language, 53
    Goals of Software Development, 54
    Guidelines for Choice of Programming Language, 55
    Recommended Policy for Requiring the Use of the Ada Programming Language, 55
Software Engineering Plan Review Process, 56
    Policy Framework, 57
    Stakeholder Role, 58


    Approval Authority and Milestones, 59
    Submission of Software Engineering Plans, 59
    Software Engineering Codes, 60
Notes, 61

Goals of the Investment Strategy, 62
Ada Investment Strategy, 63
    Language Maintenance and Enhancement, 64
    Support for Ada Compilers, Tools, and Application Programming Interfaces, 64
    Curriculum Development, 66
    Centralized Support Organization, 66
Detailed Plan for Investments in Ada Technology and Support, 66
Conclusion, 67
Notes, 68



A DOD Draft Software Management Policy Directive with Further Modifications Suggested by the Committee, 75
B Technical Descriptions of Ada and Other Third-Generation Programming Languages, 80
C Glossary, 88
D Detailed Comparisons of Ada and Other Third-Generation Programming Languages, 92
E Briefings and Position Papers Received by the Committee, 101

Executive Summary


Ada was developed in the 1970s by the Department of Defense (DOD) and adopted in some DOD programs until its use was required for new software development in 1987. It has been employed as a tool for developing quality software and as a DOD policy lever to encourage DOD organizations and programs to adopt modern software engineering principles. Changes within DOD, the software engineering community, and the commercial software industry have led DOD to reassess its programming language policy.

The Committee on the Past and Present Contexts for the Use of Ada in the Department of Defense was created by the National Research Council's Computer Science and Telecommunications Board to review DOD's programming language policy and the question of Ada's role in it. This study presents findings and recommendations developed by the Committee for DOD's consideration in efforts to revise its current policy.

The Committee concluded that a vigorous Ada program would enhance the reliability and performance of DOD warfighting systems, and it recommends that DOD continue the use and promotion of Ada in such systems. However, the committee found significant problems with the two primary components of DOD's current strategy for Ada. First, there are problems in the scope, design, and implementation of the current programming language policy, which requires the use of Ada for all software to be maintained by DOD; the committee recommends several modifications. Second, DOD's plan to discontinue investments in Ada technology and user-community support by the end of 1997 will weaken the Ada infrastructure and work against any requirement for DOD systems to use Ada in the future; given the large installed base of Ada code in warfighting systems, targeted investments in Ada are justified.

In the course of this study, the committee also concluded that the currently available data on effects of programming language on project outcomes are insufficient, on their own, to serve as a basis for strong determinations of the impact of programming language choice on the outcome of DOD


2Ada and Beyond: Software Policies for the Department of Defense

programs. Briefings received by the committee also highlighted the difficulty that DOD managers have in gaining access to data that can support informed decisions. The committee did find that trends in the data, anecdotal evidence, and expert judgment provided a basis for its finding that Ada provides benefits in warfighting systems. However, based on its experience with the limitations of currently available data, the committee makes an additional recommendation that DOD institute a corporate data collection effort and develop metrics as a sound basis for evaluating software so as to guide future policy and management decisions.


DOD's policy preference for Ada had some merit a decade ago. Most software at the time was entirely custom, and Ada had a good track record in delivering custom software with higher quality and lower life-cycle costs. However, a custom Ada solution is no longer the best approach in many application areas, due to the following major trends:

COTS as a source of information infrastructure for applications. Software solutions increasingly depend on commercial off-the-shelf (COTS) software, which provides much of an application's information infrastructure: operating system, database management, networking, user interface, and distributed processing functions. Much of this software is written in programming languages other than Ada that often do not have readily available interfaces to programs written in Ada. Developing these interfaces is not a major technical problem, but, particularly in the area of commercial Internet applications, COTS software is evolving rapidly, making it hard for Ada solutions to keep current.

Product-line solutions and production factors. Software for many application areas is achieving economies of scale through the development of product-line architectures, enabling software assets to be reused across families of applications. These product-line solutions are driven by strongly coupled "production factors," including software components, processes and methods, human resources, and expertise in particular domains. In warfighting application areas such as weapon control and electronic warfare, there is little commercial development, and DOD has established a strong community of warfighting software developers whose production factors are oriented to Ada. However, for the numerous DOD applications in which the market is dominated by commercial solutions, such as finance and logistics, production factors have been built around programming languages other than Ada, putting Ada solutions at a disadvantage.

Additional conditions that strongly influenced the committee's findings and recommendations include the following:

DOD emphasis on achieving information dominance. According to Secretary of Defense William Perry,". . . our warfighting strategy sustains and builds on . . . the application of information technology to gain great military leverage to continue to give us [an] unfair competitive advantage" (Perry, 1996a). This assertion highlights the importance of a capability for enhancing military competitive advantage as a criterion for the choice of programming language.

Large and increasing inventory of DOD Ada software. DOD now has over 50 million lines of operational Ada weapon systems software, with a great deal more under development. Most of this software is in critical warfighting application areas, and there are no quick and cheap ways to translate it into other languages. DOD policies and investment strategies that weaken Ada support for this software are very risky because of the role warfighting software plays in maintaining national security.

Executive Summary3

Proliferation of programming languages has decreased, but polylingualism is here to stay. One goal of developing Ada was to reduce the proliferation of programming languages used in DOD systems, estimated to be approximately 450 in the 1970s. The number of languages used throughout DOD has indeed decreased: the use of machine and assembly languages has diminished, and the number of third-generation languages in use has been reduced. However, there has been a rapid increase in development of fourth-generation languages by the commercial sector (there are now more than 100 different such languages), and use of these languages by DOD is increasing. Thus, DOD cannot expect to avoid polylingual software solutions. However, support for multilanguage applications has improved significantly.

Programming language choice is one of several key software engineering decisions. The requirement to use Ada and the process for obtaining a waiver isolate programming language decisions from other key software engineering decisions (e.g., choices of computer and software architectures, decisions about use of COTS components, and milestone schedules). These decisions are also currently made at the system level, rather than at the component or subsystem level. This arrangement creates an incentive for DOD programs to make decisions that are not optimal for DOD as an organization. Future programming language decisions need to be made as part of an integrated software engineering process.


The committee developed the following set of findings and recommendations for future DOD software policy and strategy. The recommendations address the use of Ada in warfighting software, the application in which the committee finds Ada to have demonstrated benefit; the proper scope and implementation of software policy; investment in Ada; and collection of data as a basis for assessing the effectiveness of software and software policy.

Ada Competitive Advantage

Finding. Ada gives DOD a competitive advantage in warfighting software applications, including weapon control, electronic warfare, performance-critical surveillance, and battle management.

Recommendation. Continue vigorous promotion of Ada in warfighting application areas.

Rationale. Available project data and analyses of programming language features indicate that, compared with other programming languages, Ada provides DOD with higher-quality warfighting software at a lower life-cycle cost. DOD can increase its advantage by strengthening its Ada-based production factors (involving software tools, technology, and personnel) for warfighting software (see Chapters 2 and 3).

Applicability of Policy to DOD Domains

Finding. DOD's current requirement for use of Ada is overly broad in its application to all DOD-maintained software.

Recommendation. Focus the Ada requirement on warfighting applications, particularly critical, real-time applications, in which Ada has demonstrated success. For commercially dominated applications, such as office and management support, routine operations support, asset monitoring, logistics, and medicine, the option of using Ada should be analyzed but should not be assumed to be preferable.

4Ada and Beyond: Software Policies for the Department of Defense

Rationale. For warfighting software, supporting Ada-based production factors (involving software tools, technology, and personnel) gives DOD a competitive advantage. In this domain, eliminating the use of Ada would both compromise this advantage and diminish the capabilities for maintaining DOD's existing 50 million lines of Ada. In commercially dominated areas, pushing applications toward Ada would create a disadvantage for DOD (see Chapters 2 and 3).

Scope of Policy

Finding. DOD's current requirement for use of Ada overemphasizes programming language considerations.

Recommendation. Broaden the current policy to integrate the choice of programming language with other key software engineering concerns, such as software requirements, architecture, process, and quality factors.

Rationale. The current policy isolates the Ada requirement and the waiver process from other software engineering decisions, causing programs to make premature or non-optimal decisions (see Chapter 1). DOD has already taken steps to broaden the policy focus in its draft revision of its programming language policy, DOD Directive 3405.1; this report recommends modifications to that draft policy (Appendix A).

Policy Implementation

Finding. DOD's current Ada requirement and the related waiver process have been weakly implemented. Many programs have simply ignored the waiver process. Other programs make programming language decisions at the system level, but often a mix of Ada and non-Ada subsystems is more appropriate (see Chapter 1).

Recommendation. Integrate the Ada decision process with an overall Software Engineering Plan Review (SEPR) process. Passing such a review should be a requirement for entering the system acquisition Milestone I and II reviews covered by DOD Instruction 5000.2. It should also be required for systems not covered in 5000.2, and recommended by DOD for DOD-directed software development and maintenance of all kinds.

Rationale. The SEPR concept is based on the highly successful commercial architecture review board practice. The SEPR process involves peer reviewing not only the software and system development plans, but also the software and system architecture (building plan) and its ability to satisfy mission requirements, operational concepts, conformance with architectural frameworks, and budget and schedule constraints; the process also involves reviewing other key decisions such as choice of programming language (see Chapter 4).

Investment in Ada

Finding. For Ada to remain the strongest programming language for warfighting software, DOD must provide technology and infrastructure support.

Recommendation. Invest in a significant level of support for Ada, or drop the Ada requirement. The strategy developed by the committee recommends an investment level of approximately $15 million per year.

Rationale. With investment, DOD can create a significant Ada-based complex of production factors (involving software tools, technology, and personnel) for warfighting application domains.

Executive Summary5

Without such support, Ada will become a second-tier, niche language such as Jovial or CMS-2 (see Chapter 5).

Software Metrics Data

Finding. DOD's incomplete and incommensurable base of software metrics data weakens its ability to make effective software policy, management, and technical decisions.

Recommendation. Establish a sustained commitment to collect and analyze consistent software metrics data.

Rationale. The five sets of findings and recommendations above are based on a mix of incomplete and incommensurable data, anecdotal evidence, and expert judgment. For this study, the patterns of consistency in these sources of evidence provide reasonable support for the results-but not as much as could be provided by quantitative analysis based on solid data. A few organizations within DOD have benefited significantly from efforts to provide a sound basis for software metrics; a DOD-wide data collection effort would magnify the net benefits (see Chapter 2).


In summary, the committee concluded the following regarding DOD and Ada:

  1. DOD should continue to require Ada for its warfighting software and should drop the Ada requirement for its other software.
  2. DOD should provide roughly $15 million per year for Ada infrastructure support, or drop the requirement to use Ada entirely.
  3. DOD should make programming language decisions in the context of a Software Engineering Plan Review process.

The rationale for the above statements is as follows:

  1. In commercially dominated areas, although Ada may offer some advantages for custom software development, the preponderance of existing commercial activity and solutions in other languages counters these advantages, thereby shifting the business case away from mandating Ada in these areas.
  2. In warfighting applications, Ada's technical capabilities for building real-time, high- assurance custom software are generally superior to those of other programming languages. DOD's investments in Ada to date have provided DOD systems with a competitive advantage in these areas.
  3. The commercial marketplace alone will not sustain a robust Ada infrastructure.
  4. A relatively modest ($15 million per year) DOD investment at the margin would be sufficient to sustain a robust Ada infrastructure for warfighting applications.
  5. DOD's inventory of more than 50 million lines of Ada warfighting software will become a liability without a robust Ada infrastructure.
  6. DOD's current Ada waiver procedure can be effectively replaced by adoption of the commercially established practice of using architecture review boards, a process that can also strengthen DOD's overall software engineering capability.

6Ada and Beyond: Software Policies for the Department of Defense


Chapter 1 describes the past and present contexts for Ada and DOD software development and programming language policy and points out problems with the current approach. Chapter 2 relates issues in decisions about programming language to other software engineering decision issues and evaluates Ada's support for software engineering processes. It also summarizes the results of comparing the relative cost-effectiveness of Ada and other programming languages, based on analyses of language features and empirical data from software projects.

Chapter 3 presents a business-case analysis for the use of Ada within DOD, gives the committee's findings and recommendations, and analyzes them along with alternatives.

The software policy recommended by the committee for DOD is elaborated in Chapter 4, which also provides additional details on programming language selection criteria and explains the basic elements of the Software Engineering Plan Review process recommended by the committee. Chapter 5 discusses the committee's recommended strategy for investment in infrastructure for Ada.

Appendix A reproduces a draft revision of DOD Directive 3405.1 on programming language policy (DOD, 1987a), a document to which the committee has added further suggested modifications that reflect its recommendations in this report. Appendix B presents detailed descriptions of Ada and other programming languages; a glossary of terms used in the report is contained in Appendix C; Appendix D compares Ada's features with those of other third-generation programming languages; and Appendix E lists briefings and position papers received by the committee during the course of its study.


The Changing Context for DOD Software Development

For nearly two decades, the Ada programming language has been a cornerstone of efforts by the Department of Defense (DOD) to improve its software engineering practices. DOD created Ada in the 1970s to serve as a department-wide standard that would satisfy its special requirements for embedded and mission-critical software, and would also encourage good software engineering. Both the new language and the new software engineering ideas associated with it met with some criticism, and both have evolved as a result. Today, Ada is the most commonly used language for mission-critical defense software, which includes weapon systems and performance-critical command, control, communications, and intelligence (C3I) systems. DOD's inventory contains nearly 50 million lines of Ada code in these applications (Hook et al., 1995). Given the long operational life of such systems, DOD has made a significant investment in Ada technology. Ada is the second most commonly used language (after Cobol) for DOD automated information systems, which include payroll and logistics programs. The DOD inventory contains more than 8 million lines of Ada code in these applications (Hook et al., 1995).

Hopes for broad commercial adoption of Ada have not been realized, however. Its commercial use has been eclipsed by other languages, such as C, then C++, and, most recently, Java. DOD's inclusive approach in the development of the language, as well as its promotional campaigns in support of Ada, do not appear to have been successful in fostering adoption of the language beyond defense and other mission-critical applications.

During Ada's lifetime, DOD's position in the software market has shifted. Although DOD still has an influence, its share of the market has diminished—not because DOD's need for software has decreased, but rather because the size of the commercial software market has exploded, generating a corresponding increase in investments in commercial software technology. DOD made significant investments to develop Ada (both Ada 83 and Ada 95)1 and mandated its use on certain DOD projects. The DOD requirement to use Ada appears to have been beneficial for custom software that has no commercial counterparts (e.g., weapon systems and performance-critical C3I software). On the other hand, this policy has frequently been counterproductive in application areas that have strong commercial support. In these areas, DOD's policy has inhibited DOD from taking advantage of existing commercial infrastructure written in or for other languages.


8Ada and Beyond: Software Policies for the Department of Defense


Commercial software includes a great deal of powerful infrastructure software such as development tools, operating systems, database management systems, networking software, user interfaces, and transaction processing programs. It also includes rich and growing sources of software for applications that are similar to some DOD applications, such as management information systems; geographic information systems; and logistics, medical, engineering and scientific, and office-support systems. With the exception of some aerospace, transportation, and safety-critical applications software, little of this commercial software is written in Ada.

In the 1990s, the computing field has been transformed by technological advances, particularly in networking and in low-cost personal computing with associated tools. While these advances have had relatively little impact on traditional real-time embedded systems, they have completely altered the character of commercial information systems and the processes used to develop them. Information systems are now commonly built with a two- or three-level client-server architecture, and with a graphical user interface that is logically separated from computational steps and from a relational database. Specialized tools and fourth-generation programming languages (4GLs; see glossary, Appendix C) have been developed for building this class of applications. Such tools and languages, exemplified by Visual Basic and PowerBuilder, are extremely efficient for building small and medium-sized applications, particularly where the demands for reliability and availability are less stringent than those for real-time embedded systems. Similar tools are now becoming available for the deployment of information systems across organizational intranets and the World Wide Web. Because in certain domains these tools and languages operate at a higher level than does any traditional programming language (including Ada), they are often the most appropriate way to prototype and develop information systems. Finally, growth in Internet-based software has increased the already rapid pace of product development in the commercial software industry.


One goal of the inclusive and extensive process undertaken to develop Ada was to create a language that would be widely adopted by the software community, beyond DOD. Utilizing commercial technology has become more important to DOD in recent years, as a combination of declining financial resources for DOD and great strides in commercial developments across all areas of advanced technology has led to an increasing emphasis on leveraging commercial technology in developing defense systems (DOD, 1994b, 1995b).

Ada has taken its place among the better known and widely used third-generation programming languages (3GLs; see glossary, Appendix C); however, it has not become as popular as its proponents had hoped. One study of programming language use estimated that Ada 83 applications constitute only 2 percent of all computer applications in U.S. inventories, and slightly more than 3 percent of all function points (Jones, 1996b). Ada is used primarily within the DOD community. Beyond that community, it has been adopted by some software developers for the civilian market, especially where there is potential defense market cross-over or where there are similar requirements, such as in commercial aviation, process control, and medical instrumentation.2 However, this commercial use is a small fraction of the total commercial software market.

Another indicator of Ada's limited market penetration is the supply of and demand for Ada-trained programmers. Jones (1996b) estimates that of the 1.92 million professional programmers in the United States, 90,000, or less than 5 percent, are Ada 83 programmers.3 In an informal review of software engineering employment opportunities advertised in two major newspapers, the committee noted that of more than 1,000 references made to individual programming languages and tools,4 fewer

The Changing Context for DOD Software Development9

than 3 percent of the citations referred to Ada; in comparison, C and C++ each accounted for more than 23 percent of the references.5 While there are many ways to look at Ada's current market share, employment opportunities and professional growth were recurring concerns expressed in many of the presentations made to the committee.

Given current conditions and probable trends, it is unlikely that the use of Ada, including the recent Ada 95 version, will grow significantly beyond the DOD-dominated and related commercial niche of high-assurance, real-time systems where it is already strong. Some of the principal reasons for this conclusion are discussed in the following sections.

Low Commercial Awareness and Limited Sponsorship

Ada has never attained the broad following associated with languages such as C++ and, most recently, Java. Market research indicates that nearly all programming language decision makers in non-defense industries are aware of Cobol, C, C++, Fortran, and Pascal, but only two-thirds are aware of Ada; only one-fifth are familiar with Ada's characteristics (Telos, 1994). 6

In decisions affecting adoption of programming languages, non-technical factors often dominate specific technical features. These factors include the broad availability of inexpensive compilers and related tools for a wide variety of computing environments, as well as the availability of texts and related training materials. In addition, grass-roots advocacy by an enthusiastic group of early users, especially in educational and research institutions, often has broad influence on adoption of programming languages. These advantages were largely absent when Ada was introduced in 1980. In contrast, C++ and Java both have achieved widespread acceptance and use. The strong military orientation of the publicity generated for Ada also may have served to alienate significant portions of the academic and research communities.

Historically, DOD has been Ada's only sponsor, and Ada has been focused almost exclusively on the military niche occupied by DOD and its contractors. In the past, Ada technology was subject to export control restrictions. The development of tools and components funded by DOD was targeted to DOD organizations and defense contractors. People and institutions outside DOD who were interested in Ada found it difficult to acquire compilers and training resources.

Many technical organizations evaluated Ada and its associated tools in the mid-1980s and decided not to use it. Most of those organizations have committed significant resources to other languages and technologies; thus they are unwilling to reconsider Ada, even though Ada 95 is significantly different from Ada 83 and the tools are far more advanced. Beyond the DOD-dominated niche, some organizations are unwilling to reconsider Ada because they continue to view Ada as a language that is suitable only for military applications.

Recently, DOD's Ada Joint Program Office has begun to promote the academic use of Ada by awarding educational grants and making lower-priced compilers available. While these activities have had an impact (see the next section), by themselves they are unlikely to be enough to make Ada popular. They have not been matched by development of infrastructure to make it attractive to the research community, where advanced software development is carried out and graduate students are trained.

Limited Extent of Academic Instruction in Ada

The popularity of a programming language in the academic world and its use in industry are often linked. Schools feel pressure to teach the languages that appear to be demanded most by the labor market. At the same time, the adoption of computer languages in the classroom can lead to commercial use.7 A manager who has been exposed to a language in school is more likely to be confident about

10Ada and Beyond: Software Policies for the Department of Defense

trying it out, and even more confident if it is one that many recent graduates appear to know. University research and development groups are also influential, since the advanced software concepts they develop tend to influence the next generation of commercial products. A language that is widely taught is more likely to be widely adopted.

Ada has not been widely taught in colleges and universities, particularly compared with Pascal, C, and C++; until recently, even the military academies taught programming in languages other than Ada. A survey of more then 2,300 colleges and universities worldwide that have computer science curricula identified only 285 institutions that offer any courses in Ada; 237 of them are in the United States (IITRI, 1996), and they include many small institutions, among them community colleges and technical institutes. Few of the leading computer science programs in the United States, as ranked by the National Research Council's assessment of graduate research programs (NRC, 1995), provide instruction in Ada: only 6 of the top 53 programs (and 1 of the top 10) were identified by the 1996 survey as offering Ada courses.

However, the IIT Research Institute's 1996 survey of Ada instruction also found that in fewer than 3 years, there was a 47 percent increase in institutions offering courses in Ada and a 43 percent increase in the number of Ada courses offered (both measured worldwide). A survey of institutions adopting Ada as a foundation language found that from 1993 to 1996 the number increased from 57 to 147 (Feldman, 1996).8 Yet the total is still comparatively small, and it is unclear how long this trend might continue without the strong sponsorship provided by DOD.

Limited Availability of Ada Tools and Compilers

Historically, compilers and other language-specific tools for Ada have been significantly more costly and slower in coming to market than those for C and C++. Initially, this was a matter of technology. Since Ada embodied new technology that provided technical challenges for compiler writers, production-quality Ada compilers were not available for several years after Ada's official debut in 1980. When they became available, they were large, slow, unreliable, and expensive. This slowed DOD contractors' transition to Ada from other languages and soured some early users. Because C compilers are much easier to build and have a higher expected sales volume, they have typically been the first available compilers for new microprocessors; C++ compilers have usually followed, and Ada compilers have often been the last to be available. The problems with Ada compilers also impeded the use of Ada in education. Thus, organizations seeking to adopt Ada faced near-term costs for new tools, especially the high-priced compilers, in addition to the cost of training people in a language that was not widely taught in academic institutions.

Currently, Ada compilers are comparable in quality to those of other 3GLs, and the increased hardware resources needed to run popular software, such as Windows 95, make the requirements of Ada compilers appear more modest. In addition, the availability of the GNU NYU Ada 95 Translator (GNAT) has reduced the cost and improved the availability of Ada compilers. GNAT is a component of the GNU compiler suite, sharing code-generation facilities with the GNU C and C++ compilers. The GNU C compiler is generally recognized as a high-quality compiler. The GNU technology makes it comparatively easy to support new processors; therefore, the GNU compiler is likely to be one of the first available when a new processor appears. A non-technical but important side benefit is the association of GNAT with the Free Software Foundation, which should help GNAT to shed some of Ada's military-only stereotype. The entire GNU compiler suite is distributed widely over the Internet, without charge, and is also distributed by some hardware vendors. In addition to the freely available GNAT, the main compiler vendors (see below) also offer academic compilers to students at reduced prices.

The Changing Context for DOD Software Development11

The market for Ada compilers and tools has been estimated at $200 million annually.9 The modest size of this market has resulted in significant consolidation of Ada compiler and tool vendors over the past few years.10 There are now two dominant suppliers: Rational Software Corporation (which was formed by the merger of Rational with Verdix, which had previously acquired Meridian) and Aonix (previously Thomson Software Products, which acquired Alsys and Telesoft). In addition, there are several other vendors that focus mainly on niche markets. These suppliers include the Texas Instruments unit that was previously Tartan, TLD, OC Systems, DDC-I, RR Software, Intermetrics, Green Hills, ICC, and Ada Core Technologies (which was formed to support and commercialize GNAT). Several of the vendors, including the two largest, have product lines other than Ada. It is not clear how this consolidation will affect the availability and price of commercial Ada compilers in the long term.

Assumption That Ada Has to Control Everything

Ada provides some services, such as input/output, multitasking, time keeping, and interrupt handling, that are traditionally in the domain of an operating system. Early Ada implementations were designed with the assumption that Ada was in complete control of the hardware, with no operating system, and that all the software on a machine was written in Ada. This approach is effective for the programming of embedded systems, in which the applications need to run without an operating system. Since Ada hides differences between operating systems, these characteristics make applications more portable.

However, these features also mean that, when compared with a language in which services are obtained by operating system calls, it is harder to write an Ada run-time system. It is also more difficult to port it to a new operating system, although this cost can be balanced by the benefit of reduced effort in writing and porting Ada application programs. In early Ada applications, when compiler vendors lacked expertise in real-time kernel building, the run-time systems were a frequent cause of complaints related to the closed nature of the interface. Developers of embedded systems applications wanted to have more direct control over the hardware resources. Developers of conventional operating system applications were hampered by the lack of access to the full operating system functionality, and by the incompatibility of libraries written in other languages with the Ada run-time system. The situation has improved in recent years; Ada vendors have adopted a more "open systems" approach in which the Ada run-time system is layered over a commercial real-time kernel or a traditional operating system, and Ada 95 supports interfaces to other languages.

Need for Ada-compatible Application Programming Interfaces

An application programming interface (API) is a set of procedure and function specifications that provides access to the capabilities of a reusable software component, such as an operating subsystem for "windows" or network communications. The vendors of most commercial off-the-shelf (COTS) software components typically provide a C-language API. For the COTS component to be usable by an Ada application, an Ada-compatible API must be provided; this does not mean, however, that the COTS product itself needs to be written in Ada (a misconception that was evident in several presentations to the committee). A vendor-provided Ada API often lags the C version by months or years (a very long time in the computer industry), and often costs more. An Ada developer can create an interface to a C- language API without vendor support, but doing so can require intimate knowledge of the particular COTS product and/or the Ada language implementation. The earlier implementation of non-Ada APIs, and greater vendor involvement, also have led to earlier standardization. Thus, the time delay and extra cost or effort of obtaining an Ada API, and the delay in standardization, have become disincentives for

12Ada and Beyond: Software Policies for the Department of Defense

the use of Ada. An added disincentive is the challenge of keeping Ada APIs current with the frequent changes in COTS product features.

Labor Market Forces

Software engineers are likely to be interested in enhancing skills that they expect to be most valuable in the software engineering marketplace, which is now dominated by commercial opportunities. Thus, programmers have moved quickly to learn Java and Hypertext Markup Language (HTML; used to develop pages for the World Wide Web) because they see these as the next wave, which can carry them to new career opportunities. Similarly, software engineers might avoid using Ada if they see it as limiting their careers. Given the cyclical nature of DOD spending, recent downsizing, and layoffs, defense software engineers have reasons to consider preparing for a move to the commercial sector. Even those who believe Ada is technically the best solution for a given program may face conflicting incentives in choosing a programming language.

On the other hand, the committee heard testimony that, for developing the specialized software that is most critical to the DOD mission, knowledge of the application domain is harder to obtain and more valuable than knowledge of a particular programming language, or even of software engineering itself. Thus, software engineers who have expertise in defense-oriented applications are likely to be in greater demand in that sector than in the commercial marketplace, where their domain-specific skills would be less applicable. Likewise, employers in the DOD sector are highly motivated to keep experienced engineers because of the expense of training new ones in the relevant applications, as well as the cost and delay of obtaining a security clearance for a person entering from the commercial market. These dynamics contribute to the separation of the military and commercial markets for software engineers, which is similar to the separation of those same markets for aerospace engineers.


Policy History

DOD's decision to design Ada as a new programming language for embedded applications was a reaction to both the "software crisis" of the late 1960s and early 1970s and the advent of software engineering concepts. It was also a response to the fact that each of the military services had developed separate programming languages that each was planning to independently standardize, upgrade, and improve. Within DOD, software problems were contributing to project cost overruns and lengthy delays in system deployment. From 1968 to 1973, the total cost of DOD's computer systems increased by 51 percent, even though hardware costs were decreasing dramatically (Fisher, 1976). While some have argued that this increase could be interpreted as the legitimate cost of obtaining new functionality, at the time it was viewed as symptomatic of software development problems.

One visibile aspect of DOD's software crisis was that systems were being developed in many different programming languages for many different computers, diluting resources and increasing the cost and complexity of maintenance. Many of the systems were written in assembly language for specialized, proprietary processors, or written in programming languages unique to a particular project or contractor. There was never a thorough count of the number of languages in use, but a widely cited estimate is "at least 450 general-purpose languages and dialects" (Hook et al., 1995). The abundance of languages made it uneconomical to develop high-quality software tools and was an obstacle to using programmers and software across projects. It was also a major source of post-deployment problems in areas such as interoperability, operations, and maintenance, and it hindered effective product-line

The Changing Context for DOD Software Development13

management. Maintenance of compilers, assemblers, linkers, and other tools for all these languages was a significant burden, as were the hiring and training of programmers. In many cases, a system could be maintained only by its original developer; such vendor "lock-in" added to maintenance expenses.

For these reasons, it appeared desirable for DOD to converge on a minimal set of programming languages. Representatives of various DOD and allied defense organizations worked together to define the DOD requirements for high-order languages. An early outcome was the release of DOD Directive 5000.29 (DOD, 1976). The directive required the use of an approved high-order language, unless another choice could be shown to be more cost-effective, and it established a single point of control for each language. However, it was determined that none of the existing languages met the requirements for embedded systems, which were estimated to represent more than half of all DOD software costs in 1973 (Fisher, 1974).

DOD decided to design a new language that would serve as the single, common, high-order language. While DOD had other software problems that went deeper than those associated with programming languages, it appeared that programming language problems were amenable to a technical solution. Moreover, the conversion to a new, common, high-order programming language was viewed by some as a vehicle for DOD-wide efforts to improve software engineering. The new DOD language, which eventually became Ada, was intended to be a modern programming language that would reflect the accumulated knowledge of programming language design and provide the appropriate set of concepts and features for implementing embedded systems.

Representatives of key stakeholders, including organizations within DOD, its contractors, and many of the world's software engineering and programming language experts, were involved in the identification of requirements, the design and evaluation of the early prototype languages, and the refinement of the preliminary Ada design. The end product, eventually named Ada 83, was officially released in 1980 and became a standard in 1983. It was recognized as a powerful, modern programming language that addressed DOD's stated requirements for embedded systems. However, Ada's adoption within DOD and by its contractors did not proceed as quickly as anticipated.

In 1983, Undersecretary of Defense Richard DeLauer established a policy mandating the use of Ada for all new mission-critical applications. The policy specified a waiver process, whereby other DOD authorized languages (CMS-2M/Y, Jovial J3/J73, Fortran, Cobol, TACPOL, SPL/l, and C/ATLAS) could also be used. While the preferential treatment for Ada helped, Ada support software was not yet mature, and there were still many contract awards across the services where Ada was not selected. As a result, systems developed in Ada continued to be in the minority. That situation led to the establishment, in 1987, of the current policy, specified by DOD Directive 3405.1 (DOD, 1987a), which prescribes the use of Ada for most DOD procurements and internal developments. The original list of approved high-order languages was expanded to include Minimal BASIC and Pascal.

The proliferation of programming languages within DOD systems, one of the original reasons for mandating the use of Ada, appears to have diminished over time. Most new DOD software is written in Ada or one of a few other languages. As of 1994, 79 percent of all DOD mission-critical software was written in 3GLs; of this code, 33 percent was written in Ada, 37 percent in the other approved high-order languages, 22 percent in C, and 3 percent in C++ (Hook et al., 1995). It is difficult to tell how much of this consolidation of language use is a result of the requirement to use DOD-approved languages, given that C— the second most widely used language in DOD— has never been on DOD's list of approved languages. Certainly larger market and industry forces have also been at work. For example, growing standardization in the computer industry has resulted in fewer new computer architectures being introduced, particularly when compared with 20 years ago, resulting in fewer assembly languages in use. Similarly, the rate of growth in new 3GLs has diminished since the 1970s and has been overtaken by development of the infrastructure and culture needed to build software involving components in different programming languages.

14Ada and Beyond: Software Policies for the Department of Defense

However, the growth of 4GLs indicates a potential for a new proliferation of programming languages. For example, one study lists 115 languages (out of a total of 455 currently active languages) that meet one definition of a 4GL, i.e., that the language requires 30 or fewer statements to encode one function point (Jones, 1996c). 4GLs typically are not intended to serve as general-purpose programming languages, but they may include a lower-level sub-language that is more general and allows users to program functionality that is not built into the 4GL. Hook et al. (1995) found that 4GLs are used increasingly for DOD automated information systems applications; the committee also heard from DOD representatives that 4GLs increasingly are being used for rapid-development special applications. Thus, it appears that DOD will continue to operate in a "polylingual" world.

Ada's Place in Current DOD Programming Language Policy

DOD policy states that Ada is to be the "single, common, computer programming language for Defense computer resources used in intelligence systems, for the command and control of military forces, or as an integral part of a weapon system" (DOD, 1987a). The policy allows for the use of other, previously authorized languages in deployment and maintenance, but not for redesign or addition of more than one-third of the software. Ada is to be used "for all other applications, except when the use of another approved higher order language [HOL] is more cost-effective over the application's life-cycle." It ranks as preferences (1) off-the-shelf applications packages and advanced software technology, (2) Ada-based software and tools, and (3) approved standard HOLs. Exceptions are allowed only by the granting of a waiver, which requires that the alternative language be more cost-effective and that it be chosen from the list of DOD-approved languages. Neither Ada use nor a waiver is required for COTS or contractor-maintained software developments or for vendor-provided updates.

Implementation of Policy on Waivers

Requests for waivers to develop systems in different languages are handled at a very high management level—the offices of the Assistant Secretary (C3I) or the Service Acquisition Executives—and are reviewed independently from the requesting program's other key decision milestones (such as the Defense Acquisition Board and Major Automated Information Systems Review Council). In practice, such waivers have rarely been requested. The committee was informed that 31 waivers had been granted since 1992 across the services (3 by the Army, and 14 each by the Navy and the Air Force). Because most requests for a waiver have been granted, this relatively small number of approved waivers suggests that only a very small percentage of the many projects that did not use Ada actually submitted a waiver request.12

Based on briefings and testimony to the committee and the information discussed above, the committee concluded the following about the implementation and some of the effects of the Ada waiver policy:

  1. Many projects have ignored or manipulated the policy on waivers, employing languages other than Ada without the required waiver.
  2. Many project managers fear that requesting a waiver will reflect badly on them; this has caused some to employ Ada where it is not cost-effective.
  3. The DOD and services' authorities generally have the capability to grant waivers that are justified, given the small number of waiver requests.

The Changing Context for DOD Software Development15

    4. The granting authorities do not have the capability and expertise to evaluate the technical merits and long-term consequences of the full number of Ada waiver requests that would be made if there were full compliance with the policy.

In organizations with a high level of understanding of software, similar waiver processes can work reasonably well. Waivers are requested by developers where they make sense; waivers are granted by managers where they make sense; and the developers and managers know enough about software to reconcile differences of opinion on what makes sense. One of the recurring themes in successful DOD projects using Ada was that Ada was selected for appropriate technical and economic reasons. However, selection of Ada solely to satisfy DOD's overall policy on programming languages has not been a guarantee of project success.

Importance of Appropriate Expertise

Custodians of mandates on software use who do not possess sufficient knowledge of software tend to rely too much on narrow interpretation of the mandates, and DOD historically has not had a high level of software expertise. The Defense Science Board found in 1987 that DOD lacked adequate career paths for software professionals and had long ignored its software personnel problems (DOD, 1987b). Testimony heard by this committee indicated that although the level of software training has increased, such problems persist. For example, cutbacks in several DOD organizations in the early 1990s appear to have caused numerous software experts to leave DOD for industry. The approach that the Defense Science Board recommended was, "Do not believe DOD can solve its skilled personnel shortage; plan how best to live with it, and how to ameliorate it."

Level of Applicability

Another recurring issue and ambiguity in current DOD policy on programming languages is that it reflects a system-level view of software that does not consider subsystems independently. For example, for a project with three subsystems—(1)an operational flight program (all new software), (2) a simulator (based on an existing simulator written in C), and (3) a ground-based test capability (combining new and legacy components in multiple languages)—current DOD policy encourages project managers to either write all subsystems in Ada or apply for a waiver for all subsystems. This approach leads to a simplistic choice between two options, neither of which is optimal. A clear, more flexible policy is needed that allows project managers to optimize programming language use at the subsystem and component level, without incurring a penalty of additional administrative overhead for the division into components.


To be effective, DOD's policy requiring the use of Ada must include positive incentives for doing so, and it must be implemented closer to the project level within DOD. The current policy fails on both accounts. It has often had negative effects on DOD software engineering processes, in particular because DOD's policy on waivers for use of alternative programming languages has been implemented unevenly by DOD staff who lack the necessary technical knowledge, understanding of the relevant details of system design, or the motivation to consider long-term and service-wide objectives. Many DOD personnel testified to the committee that waivers are perceived as difficult to defend (even though

16Ada and Beyond: Software Policies for the Department of Defense

it appears that most requests are actually granted). This perception frequently has led to manipulation, bypassing, or simply ignoring of the waiver process. Narrow interpretation of the policy has led to a number of poor decisions to use Ada, even when other solutions offered significant improvements in capability. For example, certain graphical user interface development tools have frequently not been used simply because they did not generate Ada or were not written in Ada.


DOD weapon systems programs and commercial organizations both understand that significant post-development investments are needed to keep software systems functioning effectively. For example, Citibank spends 80 percent of its software budget on sustaining and enhancing existing code.13 In the programming language area, Eric Schmidt, chief technology officer at Sun Microsystems, has stated that "several years" lie between Java and black ink (Aley, 1996). It is reasonable to assume that Ada 95 will also require ongoing investment.

DOD has assigned the responsibility for sustaining Ada to the Defense Information Systems Agency (DISA), under the Assistant Secretary of Defense (C3I). It is the committee's understanding that DISA's current plan is to shrink the originally planned budget of $10 million in annual support for Ada 95 to nearly zero by the end of 1997. The committee does not believe that Ada 95 is an exception to the general rule that software requires continuing investment to remain effective; briefings from DISA indicated that it has made an assumption to the effect that "the language exists and is mature," meaning that the commercial sector will provide support. The committee disagrees with this assessment.

The barriers to commercial adoption of Ada discussed above in this chapter are a significant concern, because without support and promotion by critical customers such as DOD and the commercial safety-critical community, there is a serious danger that the Ada tool and compiler industry will shrink to the point that it can no longer provide widespread support to warfighting systems. This will ultimately increase DOD's costs, because it will have to take over full maintenance and development for Ada tools. DOD may also have to use programming languages that will result in more costly development and maintenance for its mission-critical systems. In addition to increased cost, any decrease in quality or increase in schedule could threaten DOD's warfighting adaptability and readiness.

DOD remains the key customer for Ada technology. Although Ada 83 is being used outside DOD for the development of critical applications, the Ada tool and compiler market remains dependent on robust support from DOD. Even the perception of DOD pulling away from its support for Ada could dramatically affect Ada vendors, at a time when the industry is in the process of assimilating Ada 95. Uncertainty over DOD's programming language policy and investment strategy is already affecting the ability to find capital to invest in Ada-related development.

The most critical impact of not sustaining Ada is the consequent reduction in support for DOD's 50 million existing lines of Ada mission-critical software. Without DOD support, Ada will begin to resemble other unsupported DOD languages such as Jovial and CMS-2. Mission-critical programs relying on Ada code will be forced to choose between spending time and money to keep their Ada support current and spending even greater resources to convert their software to another language.


Tables 1.1 and 1.2 summarize the differences between the past context (1970s and early 1980s) in which the current Ada policy was developed, and the current environment. The change in context is sufficient to warrant a restructuring of DOD's policy and strategy for Ada.

The Changing Context for DOD Software Development17

Table 1.1 Past and Present Contexts for Ada: General


Some chance for Ada to be a leading commercial language Virtually no chance for Ada to achieve a commercial lead, except in niche areas
Some chance that Ada could drive other software practices Virtually no chance for Ada to become a driver of other software practices
Fair chance that Ada could become the leading high-assurance, real-time (HA/RT) language Ada generally considered the strongest (HA/RT) language in this area, but others widely used
New software mostly custom, requirements-driven New software mostly (non-Ada) COTS-driven

Table 1.2 Past and Present Contexts for Ada: Department of Defense


DOD a dominant software player DOD a large software player
Secondary role in DOD for software Primary role: key to DOD goal of information dominance
No DOD Ada legacy code 50 million lines of DOD weapon systems Ada legacy code
DOD committed to major Ada development investment DOD preparing to drop its investment in sustaining Ada


The discussion above indicates that there are serious problems with DOD's current policy regarding Ada, including the lack of guidance provided to DOD personnel and contractors for use of Ada, uneven implementation of the waiver process, and unrealistic investment strategies. In the course of responding to its charge to recommend ways for improving DOD software policies and strategies regarding Ada, the committee identified several critical questions; they are summarized below and addressed in the remainder of this report.

What is the relationship between programming languages and software engineering practices? As embodied in DOD Directive 3405.1 (DOD, 1987a), DOD's current policy for software development is a programming language policy. However, the choice of Ada as the programming language is insufficient to ensure the development of high-quality, reliable software systems for defense missions. Chapter 2 addresses the importance of software engineering practices and their relationship to programming languages, and points out connections that DOD policy should take into account; Chapter 4 discusses implementation of a broader DOD software policy.

Are there application areas where using Ada makes an appreciable positive difference? In application areas where powerful non-Ada commercial software support is available, Ada is unlikely to be cost-effective. However, for some DOD software applications, there are few commercial counterparts, and Ada may have advantages. These issues are discussed in Chapters 2 and 3.

18Ada and Beyond: Software Policies for the Department of Defense

If Ada is superior in some areas, is a policy requiring its use appropriate? This issue and a number of other policy alternatives are discussed in Chapter 3.

For whatever policy requirements are appropriate, can DOD establish a workable set of criteria and processes for recognizing exceptions? These issues are discussed in Chapter 4 and are addressed in committee-suggested modifications of a May 1996 DOD draft software management policy presented in Appendix A.

What specific investment strategies are needed to keep Ada strong? This issue is discussed in Chapter 5.


  1. The cost to DOD of developing Ada 95 has been estimated by the Ada 95 program manager, Christine Anderson, as being in the range of $29 million to $35 million (personal communication, July 5, 1996). Ada 83 investments were likely much greater but are difficult to quantify.

  2. For descriptions of non-DOD projects using Ada, particularly in aerospace, transportation, and telecommunications, see "Ada Success Stories," maintained by the Ada Information Clearinghouse, located on the World Wide Web at

  3. If all programming activities are included (i.e., application-oriented programming by other professionals), the total number of programmers increases to 3.45 million, less than 3 percent of which are Ada 83 programmers.

  4. The newspapers were the April 21, 1996, edition of the Los Angeles Times and the March 24, 1996, edition of the Washington Post.

  5. Other significant 3GLs were Cobol (11 percent) and Java (4 percent). Significant 4GLs were Visual Basic (13 percent), PowerBuilder (10 percent), and FoxPro and Visual C++ (4 percent each).

  6. The industry groups surveyed were automobile services, financial services, medical devices, and industrial machinery.

  7. Exceptions to this generalization include Cobol, which was never a popular language in academia but is used widely in business and defense applications, and Pascal, which was popular for many years in universities but not in industry.

  8. "Foundation" is defined as one of the initial computing courses taken by students majoring in the field.

  9. Bob Mathis, executive director, Ada Resource Association, personal communication, September 8, 1996.

  10. The committee included representatives of two firms that sell Ada products: Rational and Intermetrics.

  11. In a position paper to the committee, Victor Vyssotsky advocated stronger encouragement for programmers to learn numerous languages (Vyssotsky, 1996).

  12. As detailed above, only one-third of the 3GL code written for weapon systems is in Ada. Because any software produced since the policy went into effect in 1987 (except for software not maintained or upgraded by DOD) would require a waiver, many more than a few waivers each year should have been approved for weapon systems alone. In addition, the use of Ada for automated information systems in DOD is even lower in relative and absolute terms.

  13. Gerald Pastemack, Citibank, presentation to the committee, May 23, 1996, Washington, D.C.

National Research Council: Ada & Beyond
[Contents] [Part 1] [Part 2] [Part 3] [Part 4] [Part 5] [Part 6]