From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=BAYES_05,INVALID_DATE, MSGID_SHORT autolearn=no autolearn_force=no version=3.4.4 Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!rochester!pt.cs.cmu.edu!sei!ajpo!eberard From: eberard@ajpo.sei.cmu.edu (Edward Berard) Newsgroups: comp.lang.ada Subject: The U.S. DoD in Software Fantasyland Keywords: conflicting messages Message-ID: <465@ajpo.sei.cmu.edu> Date: 12 Feb 89 22:18:45 GMT List-Id: THE STORY HAD AN ENCOURAGING BEGINNING Most of you know how the story begins. It is the early 1970s, and the U.S. Department of Defense (DoD) has decided that it is spending too much money for software. To make matters worse, the software is typically late, overbudget, and filled with bugs. A study is conducted in 1974, and, in 1975 the Higher Order Language Working Group (HOLWG) is set up. The mission of the HOLWG is to first define "good software engineering" and then to identify programming languages which supported the same. By 1977, it became evident that existing programming languages fell far short of the desired objectives. It was decided that a new language was both desirable and feasible. Along the way, some realized that a programming language would not be enough. Concepts like the Ada Programming Support Environment (APSE), the Software Engineering Institute (SEI), Software Technology for Adaptable Reliable Systems (STARS), and Ada Software Engineering Education and Training (ASEET) would also be needed. These, and other, parts of the Ada technology infrastructure were created and put in place. A good number of spokespersons toured the countryside with slides showing how important and critical software was to the welfare of modern weapons systems. They explained that the demand for software was increasing exponentially, and that software was being used in increasingly critical applications. They stressed that the DoD wanted not only more software, but also more reliable, and less expensive software. The entirety of the Ada effort -- not just the programming language -- was intended to address the increased emphasis and dependency on software. It appeared hopeful that the software community would get the message that the DoD was serious about better engineered software. THINGS HAVE NOT GONE TOO WELL Almost from the very beginning, the software community, as a whole, thought that the DoD was peddling "some new programming language snake oil." Although there was some attempt to publicize the other aspects of the technology (e.g., SEI, STARS, and ASEET), these efforts were very weak. There is still a great deal of confusion. Anti-Ada mythology is rampant, e.g.: "Ada is PL/1 re-visited," "all Ada compilers generate object code which is 10 times larger and slower than that generated by most C compilers," and "only those who are forced to use the Ada language are the ones using it." Some of Ada's "friends" have not been very helpful either. Pro-Ada mythology is also present, e.g., "merely writing an application in Ada makes that application highly portable and reusable," "conversion to Ada is relatively quick and easy," "mere exposure to the language will cause programmers to see the underlying software engineering principles and will result in improved software." There is still a great deal of confusion about what Ada is all about. Although the SEI is alive and well, many DoD managers and independent contractors have little idea of what it is and what it can do for them. STARS is having a very difficult time. The term APSE has been so misused as to be almost meaningless. Contracting offices have little guidance on determining the level of Ada proficiency for a potential contractor. THAT IS NOT THE WORST OF IT One of the biggest problems in the DoD's attempt at a technology transition is that it sends out conflicting messages, i.e.: - Sound software and excellence in software engineering are very important -- in fact, crucial - The creation, maintenance, management, and other activities associated with software are not that important -- in fact, the approaches we have used in decades past are sufficient. In my travels, I have come across many frustrated government software engineers. Consider the following examples: - At a Naval installation on the west coast: After a number of tours at sea, some navy personnel were offered "desk jobs." These positions were essentially management positions, with some of the positions being software-related. It was made quite clear that if a software position was selected, the person selecting the position would no longer be considered a professional, i.e., software personnel were not professionals. - At an Army installation: I met more than one person with a masters degree in computer science who was not considered a professional because they had elected to work with software. Curiously, someone with a bachelors degree in electrical engineering could work with software, and still be considered a professional -- as long as they were hired as an electrical engineer. - At an Air Force base: An Air Force officer informed me that even though his duties seemed to require a great deal of college-level coursework (even a degree in computer science), his position was not considered to be a professional one. The message was that just about anyone with "a little training" could fill his shoes. The training policies, procedures, and qualifications within the DoD remain largely as they have been for the past twenty years. It seems that all that is required to gain entrance to most software training is a high school diploma. Many managers actually believe that after a few weeks of classroom training, someone is qualified to work as a "software engineer." (If you can write code that compiles and executes, what else is required?) In short, although there have been vast advances in software engineering technology, and software is being used in increasingly critical applications, the DoD seems to feel that the attitudes, training, and policies that were appropriate for software a quarter of a century ago are still largely appropriate today. This is not only unacceptable, it is dangerous. WHAT IS NEEDED First, the DoD must realize that it is 1989 -- not 1965. Large advances in software engineering technology have been made. Much of this technology requires college-level education if it is to be used effectively. The DoD must begin to treat those who choose software engineering (as a vocation) as professionals. Most importantly, if the DoD contends that software is critical, it must carry this concept to its logical conclusion and place stricter qualifications on those who engineer and manage software. -- Ed Berard Phone: (301) 695-6960 FAX: (301) 695-7734