Ada - DoD HOLWG, Col Wm Whitaker, 1993
The computer programming language, Ada, was the outcome of one part of a rare engineering project initiated and technically managed at the level of the Office of the Secretary of Defense (OSD), specifically, by the Office of the Director of Defense Research and Engineering (DDR&E). This paper describes the early days of the project in which the development of Ada took place. However, the purpose of the project encompassed more than just another language definition and development. This paper covers the broad project, but not the internal details of the winning language design team effort led by Jean Ichbiah.Since the Ada effort was an extraordinarily open project, all the concrete information about it is already a matter of public record. In addition, there have been a number of summaries [Carlson, 1980], one in the front of most every Ada book, for instance. This raises the question of what this paper is going to add to this literature. My goal is to add a firsthand perspective of the details that get lost in the textbooks, to provide insight into DoD handling of a project like this, and to point out some of the transient aspects that seemed very important at the time. This will put a very personal slant on the presentation; it is as I remember it.
Since this a personal history, I will give some background about how I became involved. I spent 15 years at the Air Force Weapons Lab (AFWL) at Kirtland AFB, New Mexico, then the largest scientific computing organization in the DoD. Over this period software programs had gotten much larger and more expensive, but tools and support had not kept pace. With each new machine, operating system, or compiler it appeared that all the common, first-level tools had to be regenerated. I wrote various tools half a dozen times over the years, and finally felt like giving up. The tools never got out of the first generation because one could not build with confidence or share with others who had different machines. We did manage to greatly improve the applications codes because each was supported by several people full time. Like everyone else, we did not usually worry if that code was portable since we initially did all the production in-house. This was fine locally, but bad for the DoD. Finally a very elaborate and successful porting system was implemented, but it was only for applications code.
In the late 60's, several manufacturers were the designing next generation of supercomputers. As a major potential customer, AFWL was involved to determine how our software would mate to their designs, if the code could be structured for their architectures, parallel, pipeline, or otherwise. As a customer, we were in a favored position and had access to the proprietary designs of each manufacturer. I discovered that each was planning a different FORTRAN-like language extended beyond the 1966 standard. I proposed that it would be more convenient for the customers (namely the government), and for competitive evaluations, if the language could be common, so far as was feasible. This thought was violently rejected by all parties without any discussion. I considered this attitude to be very short-sighted on the part of the manufacturers. Nevertheless, the thought stayed with me, and might be considered the genesis of the DoD common language program.
When I came to OSD in January 1973, the office to which I was assigned had recently had its name changed from Electronics and Computer Sciences (E&CS) to Electronics and Physical Sciences (E&PS), which showed that computers stood very low in the Services' research pecking order. I was responsible for the Service basic research (6.1) programs, advanced weaponry research (since I was from the Weapons Lab), and any computer activity I could find.
In 1973 I initiated the DoD "Software Initiative" to reduce the "High Cost of Software". (There have been several later "Software Initiatives" in the DoD, but this was the first and must have been well received as a talking point since the name has been reused.) While conducting "math area" research reviews in April, I was struck by the total lack of DoD research into improving the development of operational software. This seemed like a major DoD problem to me but there was no recognition of it by the Service research organizations (Army Research Office (ARO), Office of Naval Research (ONR), and Air Force Office of Scientific Research (OSR) - known collectively as the OXRs). The Defense Advanced Research Projects Agency (DARPA) supported computer research, but none of it was directed toward operational software, and DARPA was not under my control anyway. The Service research organizations were reasonably responsive to someone who can hold up their money, so I tasked the OXRs to explore the area of software for possible research opportunities. That summer a "Symposium on the High Cost of Software" was organized at the Navy Post Graduate School in Monterey [Monterey, 1973].
At the symposium, Barry Boehm of TRW gave the keynote speech. He had just completed a study sponsored by the Air Force Space and Missile Systems Office (SAMSO) on Command and Control Information Processing for the 80's (CCIP-85). Volume 4 [SAMSO, 1972] of the study (originally Volume 6) - the one on software - estimated that the Air Force was spending over $1.5 billion a year on software, which was often late and unreliable, and that the costs were rising. This was a shocking conclusion at the time, and the dollar estimates, now seemingly small, were rejected out of hand. When the Air Force published the rest of the study but refused to publish this volume. My boss, George Heilmeier, Director of E&PS, thought that was inappropriate and obtained its release by suggesting that he might find it necessary to copy and distribute such critical information within the Pentagon, if the Air Force did not do so.
At that point I met David A. Fisher from the Institute for Defense Analyses (IDA), a DoD funded "think tank" from which each OSD office could request some support. E&PS asked for an IDA study to validate Boehm's figures. It was not that we doubted the figures, but that we needed all the documentation we could get if we were to initiate a major effort. Further, IDA could draw on Pentagon figures and get a different perspective on software costs. Fisher did the IDA study [Fisher, 1974] and substantiated the Boehm figures exactly, but by an entirely different procedure. He so impressed us that he was co-opted into the follow-on project.
We got some agreement that software cost and reliability was a problem, but the question was - what could be done; more specifically, what could be done by OSD? We got the problem passed to the Services in the annual Budget Memorandum of the Secretary of Defense, which is raising it to the "highest level" in the DoD. The question was then what programs OSD should enter into to solve the problem?
We had identified the proliferation of programming languages as having a major impact on costs, or at least, this proliferation made it effectively impossible to do anything to improve the cost picture. At this time each of the Services had programs to develop unique languages, computer architectures, and hardware. Their previous efforts certainly had not reduced the cost of software, and none of these programs was likely to do so either, but maybe a joint effort could. I figured that a common language for use throughout the DoD would be a first step to building an engineering discipline of software, to supersede the then current "black art". My initial proposal was that a common language would facilitate the development of common tools, techniques, training, and metrics, and would not coerce, but enable, the sort of cooperation and long-term development that characterizes a scientific or engineering culture. Key to the payoff from the project was the expectation that a common language would promote the production and use of common tools and reusable code. Early economic analyses concluded that half of the benefit of a single powerful language would be from its technical merits, and half simply from the advantages of commonality.
This was the DoD and it took a while to get organized. During that time (1974) I was encouraged by a number of people; chief among then was Bernie Zempolich of the Naval Air Systems Command (NAVAIRSYSCOM). He had just returned from the Industrial College of the Armed Forces (ICAF), where after graduation he remained as the first civilian Research Fellow. His study was entitled "An Analysis of Computer Software Management Requirements for Operationally Deployable Systems". We interacted when he was the Command Technology Manager for the Navy All Applications Digital Computer (AADC). He became a founding member of the project. In fact, before the working group was established, his pioneering work in this area gave impetus and technical support to the entire DoD thrust. During the early years of the project, he served as secretary and spokesman. He contributed enormously to the early work of the project. These contributions - technical, administrative, and policy - established the future direction of the program. "Credit" also goes to him for jokingly dubbing the future HOL with the acronym "DOD-1".
The starting position in 1974 of the Common DoD High Order Language Program was to produce a minimal number of common, modern, high order computer programming languages for Department of Defense embedded computer systems applications and to assure a unified, well-supported, widely available, and powerful programming support environment for these languages. This was an intuitive statement of the task. To obtain acceptance, a justification had to be made, especially to initiate an effort at the OSD level, rather than the usual Service programs. We had to make sure we were addressing the real problem, rather than just doing what was easy, in order that this be a needs-driven engineering development, not a research exercise.
The total cost of DoD software increasingly attracted the attention of the highest levels of management within the Department of Defense. Cost studies estimated that the then-annual expenditure of funds for software within the DoD was in excess of $3.0 billion dollars (small now, but impressive at the time). A large portion of these growing software costs represented increased performance requirements and the transference of efforts previously considered a part of the hardware system design. The percentage of this amount that was susceptible to reduction through technical improvements could not be precisely determined. However, there was extensive anecdotal support visible to OSD in frequent reports of software development troubles indicating that the percentage would be significant, especially when the indirect costs of schedule slippage and system readiness problems attributable to software development delays and poor reliability were included.
Software costs include the design, development, acquisition, management, and operational support and maintenance of software. Only a small fraction of these tasks are involved with the functions which are defined by the Federal Government as Automatic Data Processing, those functions that have their exact analogy in the commercial sector and share a common technology, both hardware and software. A much larger fraction, more than 80%, of the DoD's computer investment is in computer resources which are embedded in, and procured as part of, major weapons systems, communications systems, command and control systems, etc. In this environment the DoD found itself spending an even larger share of its systems resources on software.
At this point I must offer some definitions, and explain how they came about. Computers in the DoD are of two general varieties. Automatic Data Processing (ADP) covers those "stand alone" systems that do ordinary commercial computer jobs: accounting, financial management, payroll, inventory, word processing, etc. The other kind, now popularly called Embedded Computer Systems (ECS), are those "embedded" in aircraft, missiles, tanks, shipboard, etc. An ECS can be a computer-on-a-board, or a special purpose device hardened to heat, cold, gravitational pull (g's) and electromagnetic or nuclear radiation. Or it may be an ordinary commercial machine operating in the traditional air-conditioned room, indistinguishable from the hardware in accounting.
The distinction is not hardware, but under what set of regulations the computer is procured. Historically there have been two computer hierarchies in the DoD corresponding to two different responsible Committees of the Congress. ADP is administered under provisions of the Brooks ADP Act (Public Law 89-306) and through Comptroller organizations in the DoD. For these systems there is a set of rules designed to eliminate duplication and promote competition in that part of the computer industry that concerns itself mainly with the private sector, and deals with roughly interchangeable products and simple economic judgements.
Weapons systems are handled and monitored (oversight) by different Congressional Committees and by different organizational elements in the DoD responsive to those Committees. At the time of the HOLWG, this was DDR&E at the OSD, and the Service Assistant Secretaries for Research and Development. There was a "5000 Series" of regulations (DoD Directives and Instructions) to govern weapons systems, including their computers. In the early 70's these were generally called "weapons systems computers". A short time later they were called "embedded systems" to convey the message that also they included functions such as control, communications, and intelligence systems, not just bombs and guns. More correctly, the name referred to the fact that they were procured as part of an overall system, not to their being physically "embedded" in a weapon. Nevertheless the image of "embedded" is strong and this has become the popular expression. Later an Appropriations Act invented the name "mission critical", which is certainly morale boosting anyway. Any attempt to parse these terms out of historical context is doomed.
These distinctions may seem esoteric to an outsider, but within the DoD the great religious conflicts of history pale to insignificance by comparison. The software initiative was specifically for defense system, developed under the 5000 series of regulations, and was originated by the organization (DDR&E) in charge of those systems. However, there was no intent to exclude the ADP applications or their problems. Indeed, there was an active liaison and consideration of this area during the whole process, but all the documents were very carefully worded to make sure they were within the proper administrative scope.
In determining the scope of the problem we set out to address the "tall pole in the tent", that is, the major portion of DoD software costs associated with Embedded Computer Systems, software integral to defense or weapon systems, including target detection and tracking, weapons direction, communications, command and control, avionics, simulators, test equipment, and other such applications and their run-time support systems. Additionally, software which supports the design, development, and maintenance of such systems must be included when identifying total costs. Within this systems environment, the DoD found itself spending an increasingly larger share of its financial and manpower resources on software. While programming language commonality throughout the DoD would not, by itself, make software less expensive, it would enable a large number of technical and managerial initiatives leading to such savings. And it was something that was uniquely within the scope and power of OSD to implement.
Another consideration was the impact of software on hardware costs. We were entering a period in which there was the expectation that systems should become much more responsive and flexible because they were controlled by "easily changeable" software, rather than hardwired hardware, practically impossible to modify. This enormous advantage would be realized only if software really was modifiable. There was a growing experience that assembly language "spaghetti software" was becoming more difficult to modify and maintain. Clearly some change in the way we were doing business was necessary.
The ultimate hardware advantage from software is the potential for switching out a piece of obsolete and expensive hardware for new smaller, cheaper technology. Much of the obsolete hardware in the field was being kept because the software would run on no other machine. It may be that the contractors were not eager to change this situation, since such old hardware required a lot of expensive maintenance and probably only the one that made it could keep it up. But the DoD was left with systems for which the yearly maintenance cost might exceed the cost of modern hardware.
A corollary to this situation is that when hardware was selected at the beginning of a major development, it was sure to be obsolete 10 years later when the system was in the field. Unfortunately it could not effectively be upgraded. These weapons systems implications are not unlike those for general ADP; however, the application must color the requirements. Software transportability (like reuse) was a major factor to the DoD, but not to an individual manager with a three month horizon.
While significant progress had been made in achieving commonality in computer hardware and software for scientific and business applications, the physical and real-time constraints imposed on embedded computer systems placed technical obstacles in the path of commonality efforts for these systems. Additionally, in the case of scientific and business systems, there had been a powerful incentive for the computer industry to develop standards (FORTRAN and COBOL) as a marketing tool. This incentive had not been present in the development of embedded computer systems for the DoD. On the contrary, it could be argued that short-term management goals (contractor and government) encouraged proliferation.
Another factor in the decision was that at that time, the DoD had a greater influence on software technology than on hardware. Some years previous, the DoD was the major innovator and consumer of the most sophisticated computer hardware possible. By 1974 the DoD represented only a small fraction of the total commercial market. In software, that unique position still existed. A significant fraction of the total software industry was devoted to DoD related programs and that was true in an even larger proportion for the more advanced and demanding systems. Thus, there was both an opportunity and a responsibility in the software arena, which was long past for hardware.
To summarize, the logic of the initiative was as follows: The use of a high order language reduces programming costs, increases the readability of programs and the ease of their modification, facilitates maintenance, etc. and generally addresses many of the problems of life cycle program costs. A modern powerful high order language performs these tasks and, in addition, may be designed to serve also in the specification phase and provide facilities for automatic test. A modern language is required if real-time, parallel processing, and input/output portions of the program are to be expressed in high order language rather than assembly language inserts, which destroy most of the readability and transportability advantages of using an HOL. A modern language also provides error checking, more reliable programs, and the potential for more efficient compilers.
Many of the advantages of a high order language can be realized only through computer tools. A total programming environment for the language includes not just compilers and debugging aids, but text editors and interactive programming assistance, automatic testing facilities, extensive module libraries, and even semi-automatic programming from specifications. Universal use of these tools can significantly reduce the cost of software and lead to the development of more powerful tools. The average DoD programmer's tool box was rather bare in the 1970's. Because of the difficulty of preparing these tools for each new language and machine and operating system, and the time involved, only the very largest projects had been able to assemble even a representative set. While in many cases development of tools can be shown to be desirable in the long run, day-to-day pressures not to perform the tool development activities usually prevailed. The use of a common high order language across many projects, controlled at some central facility, allows the sharing of resources in order to make available the powerful tools which no single project could generate. It makes those previously generated tools available at the beginning of a project, reducing star-up time.
Reducing the number of languages supported to a minimal number, therefore, should provide the greatest economic benefit. There are costs associated with supporting any particular project and general costs of supporting the language. For a sufficiently large number of users, presumably the basic cost would be proportionally less. Perhaps 200 active projects contributing to a single support facility may not be much cheaper than two facilities each supporting 100 projects. There are, however, unique advantages to having a single military computer language. For a single language, one could reasonably expect that language to be supported on new computers with a compiler (based upon the experience of the British with their common language effort, CORAL). Such support is not a reasonable expectation with five or ten common languages. Indeed, for a single common language, its use in DoD and the provision of tools by the DoD could make it a popular candidate for use elsewhere. The multitude of languages adopted by the military in the past (excepting FORTRAN and COBOL) did not receive this sort of acceptance. A single powerful supported high order language might even be expected to influence academic curricula, improving the training not so much of individual programmers but the understanding and capabilities of the general engineering community for support of DoD programs.
During 1974, elements in each of the Military Departments independently proposed the adoption of a common programming language for use in the development of major defense systems within their own Departments and undertook efforts to achieve that goal. Those efforts included the Army's Implementation Language for Real-Time Systems study, the Navy's CS-4 effort, and the Air Force's High Order Language Standardization for the Air Force study. Additionally, the Defense Communications Agency had pursued the "Development of a Communications Oriented Language". The fact that each of the Military Departments independently sought a standard military language to supplement COBOL and FORTRAN illustrated the need for a DoD-wide coordinated approach, as well as its timeliness.
Nevertheless, the proposal for language commonality across DoD was extremely radical at the time and initially met almost universal opposition. In fact, it was regarded as unrealistic to expect to use a high order language for embedded systems. It may be surprising that a consensus did not mandate a common high order language for embedded systems much earlier. There are, however, a number of managerial and technical constraints that acted against this. For many DoD systems, severe timing and memory considerations were dominant, governed by real-time interaction with the exterior environment. Because of these constraints, and restrictions in developmental cost and time scale, many systems opted for assembly language programming. This decision was influenced by past experience with poor quality compilers and the fact that an assembler routinely comes with the machine, while the compiler and its tools usually must be developed after the project has begun. The advantages of high order languages, however, were compelling, and more systems turned to them. Because of limitations of available high order languages, the programs generated often included very large portions done in assembly code and linked to an HOL structure, negating many of the HOL advantages.
Further, many systems found it convenient to produce their own high order language or some incompatible, dialect of an existing one. Since there was no general facility for control of existing languages, each systems office did the configuration control on its language and compilers and continued this for their particular dialect through the entire maintenance phase of the system. This had the effect of reducing the contractual flexibility of the government and restricting competition in maintenance and further development. This lack of commonality negated many advantages of high order languages including transportability, sharing of tools, the development of very powerful tools of high efficiency and, in fact, not only raised the total cost of existing tools, but in some cases essentially priced them out of the market. Development projects were very poorly supported and forced to live with technology far below what should be the state-of-the-art.
The target for a major language project was to be DoD "software in the large". This is often given a limited interpretation, namely that DoD programs are individually large, which is certainly true and drives many of the technical requirements on the language. But the fact that the DoD has hundreds of such large programs provides an opportunity for economies of scale that are potentially much greater than the sum of individual projects. The problem is not just that of producing a subsystem of 200,000 lines of code, but of the servicing of a "system" that is all the code produced by the DoD for (by 1990) $30 billion per year ("programming in the very large"). This path drives other requirements and properties, like machine independence which forces the validation requirement and the rejection of subsets. But these advantages can be realized only if the technology is applied with consistency over the whole of the DoD, and an even larger community if possible. So a strong position from the DoD was vital to the plan.
The process of building a constituency for the Software Initiative began with the setting up of a fairly informal Weapons System Software Committee between DDR&E and OSD Installations and Logistics (I&L), the branch responsible for maintenance. I represented DDR&E and R. D. "Duke" Hensley, who made a very large contribution in this starting year of 1974, represented I&L. Meetings involved discussions of the software problem and possible actions. From this grew the nucleus of the DoD language project and the coordination that led to the establishing memo.
In December 1974, this Committee was renamed the Weapon System Software Management Steering Committee (SMSC) in a memo "Management of Weapon System Software" by M. R. Currie, A. I. Mendolia, and T. E. McClary and added representation from the Office of the Assistant Secretary of Defense (Comptroller) (ASD (Comp)), to study the general area of software management for weapon systems. This committee was later renamed the Management Steering Committee for Embedded Computer Resources (MSC-ECR). Barry DeRoze from I&L became the first Chairman. He was the prime mover in the OSD arena for coordination of the Directives. This position was later occupied by H. Mark Grove, who shepherded the formation of the Ada Joint Program Office (AJPO) in 1980.
The enabling memo [Currie, 1975a] (Figure 1) for a DoD High Order Language Working Group (HOLWG) was issued in January 1975, but by that time the work was fairly well under way. The technical work proceeded in the HOLWG. The SMSC drafted DoD Directive 5000.29 [DoD1976b], which formally established the committee and renamed it as the MSC-ECR. Then the HOLWG formally became a subcommittee of the MSC-ECR and in November 1976 a HOLWG Charter was formalized, long after the fact. It all sounds a little baroque. These dates, which are the "facts" of history that an outsider might find in the records, have nothing to do with what was actually going on. There was a studied and logical progression, but the paper trail was constructed after the fact to please those who needed boxes filled.
The MSC-ECR took care of much of the general administrative coordination. It wrote and coordinated DoD Directive 5000.29 and DoD Instruction 5000.31. On January 31, 1977, the MSC-ECR issued an Issue Paper 77-1 recommending authorization to proceed with the preliminary design phase for a common language, with $300,000 from each Service. Throughout the lifetime of the program monies were allocated as necessary. While prudent management was exercised, this was recognized as an important program and there was never any funding or timing constraint imposed from above after approval to proceed to the next step.
The MSC-ECR also sponsored economic analyses of the benefits of language commonality. This was a necessary step in the formal process. The MITRE Corporation performed an economic analysis of language commonality [Clapp, 1977] under the auspices of the MSC-ECR and ASD(I&L). An automated decision analysis sponsored by DARPA was generated by Decision and Design Incorporated [Fox, 1978] to investigate introduction strategies and benefits. The HOLWG internally generated a program to quantify economic benefits [HOLWG, 1977c]. These were targeted to questions of expectation of savings to the Department of Defense resulting from the successful completion of this program. They further examined various introduction strategies and rates. Significant savings were demonstrated, and these were magnified by rapid introduction. Savings of hundreds of millions to tens of thousands of millions of dollars were independently derived.
As a result of these studies and of general concerns, the program was exceptionally well supported at OSD. Monies were always made available once a decision was made. However, since this program was a new start and not in the five-year plan, this often meant persuading the Services to divert funds from other projects. No schedule was imposed from above, but there was a feeling that this was a fleeting moment of opportunity.
| PREVIOUS PAGE | CONTENTS | NEXT PAGE |