eberard@ajpo.sei.cmu.edu (Edward Berard) (02/13/89)
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
rich@jpl-devvax.JPL.NASA.GOV (Richard Pettit) (02/14/89)
>........excellent discussion on how software engineers are viewed as >nothing more than clerks that know the square root of 25............ This is a very crucial issue in the software community, it is my opinion. It is additionally painful when discussing the issue in light of the decisions made about Ada over the past decade. However, the problem proliferates throughout the language and application spectrum. Cobol programmers garner no more respect from other software professionals than they do their employers, yet the lions share of the financial software that keeps the world running is written with this language by these people. And I don't think I need even discuss the "UNIX mentality" stereotype. Yet, regardless of the criticality of the application, or the general opinion of the language, software engineers have to be taken for what they are: engineers. There is something very large and very important missing in the profession of software engineering. This is probably a system for giving software professionals credentials. And rating the criticality of a software system on the basis of how many and at what level credentialed professionals are required to complete the project. The problem with this is that the people appointed to develop such a credential system would be E.E.s and people with their M.A. in education. I don't have an answer. It's just that his topic really causes me grief. It's just that I thought that after four years of grueling study in computer science that I'd be working in a REAL professional environment. Right. -- rich@jpl-devvax.Jpl.Nasa.Gov
billwolf@hubcap.clemson.edu (William Thomas Wolfe,2847,) (02/14/89)
From article <4422@jpl-devvax.JPL.NASA.GOV>, by rich@jpl-devvax.JPL.NASA.GOV (Richard Pettit): > Cobol programmers garner no more respect from other software professionals > than they do their employers, yet the lions share of the financial software > that keeps the world running is written with this language by these people. > And I don't think I need even discuss the "UNIX mentality" stereotype [...]. > There is something very large and very important missing in the profession > of software engineering. This is probably a system for giving software > professionals credentials. There's a similar discussion going on over in comp.software-eng re: the general lack of good Master's in Software Engineering programs, especially since the Wang Institute lost its funding from Wang Corporation & folded (It *had* offered a rather good MSE program, alas). On the positive side, Carnegie-Mellon is about to offer such a program. > The problem with this is that the people appointed to develop such a > credential system would be E.E.s and people with their M.A. in education. There's currently a rather shabby CDP (Certificate in Data Processing) system, which requires that you be able to answer unbelievably simple questions and that you know something about primitive COBOL concepts. Obviously, we have a long way to go. > I don't have an answer. It's just that his topic really causes me grief. > It's just that I thought that after four years of grueling study in > computer science that I'd be working in a REAL professional environment. It's damn hard to cause social change, which is what the impact of Ada on the software community amounts to. We're trying to eliminate the "hacker" mentality, trying to upgrade the skills of a lot of poorly educated COBOL people (some would say "COBOL robots"), etc. It's hard work, requiring activism on the local level from everyone who knows the score. I've found the distribution of articles such as "Ada Programming Language Improves Software Development" (from the December 1987 issue of the DPMA magazine _Data Management_) to be helpful in establishing basic receptiveness among COBOL types, in conjunction with explanations of concepts such as recursion, concurrency, exception handling, etc., which cause them to realize exactly how far behind they are. The primary problem to date is that many sites are vendor-dependent, and Ada bindings to products like CICS, DB2, etc. are only now being built as IBM rushes to play catch-up. Until this happens, it's difficult to present detailed transition plans to the people in charge. With patience and dedication, we CAN win the war. Major companies such as Shell and Reuters are forging ahead with Ada strategies. In time, even the Dod will come around... :-) :-) :-) Bill Wolfe, wtwolfe@hubcap.clemson.edu