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.8 required=5.0 tests=BAYES_00,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!gatech!mit-eddie!genrad!decvax!ucbvax!ADA20.ISI.EDU!EBERARD From: EBERARD@ADA20.ISI.EDU (Edward V. Berard) Newsgroups: comp.lang.ada Subject: Ada Education and Training - Part 1 Message-ID: <8705011313.AA15200@ucbvax.Berkeley.EDU> Date: Fri, 1-May-87 07:12:44 EDT Article-I.D.: ucbvax.8705011313.AA15200 Posted: Fri May 1 07:12:44 1987 Date-Received: Sat, 2-May-87 16:36:38 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet List-Id: It has happened again. Some DoD contractor has contacted our company for some "Ada training," and has described a "recipe for disaster." Let me fill you in on the details: 1. Apparently this contractor was awarded a contract even though there is little evidence to suggest that anyone working on the software has any real Ada experience. (You know how this works - pick a scenario: a) the contractor added the word "Ada" to the list of languages on the resumes at the back of the winning (?) proposal; b) the contractor assured the naive contracting office that the technical staff would have "adequate Ada training" by the time any software was written; c) the contractor used resumes of "qualified" individuals who are too busy on other projects to be assigned to the current project, so management thought that they could either hire someone with the needed skills by the time the coding started, or provide some absolute minimum of training to the people actually assigned to the project.) 2. Not realizing that Ada technology impacts the entire software life-cycle (including business practices), management has waited until the coding is about to start to train their technical staff in what, to the management, is "just another programming language." 3. Not wanting to waste any money on "software foolishness" (after all, the management believes that it is the hardware engineering/mathematics/science that is the "real work"), management has dictated that the "Ada education" will consist almost entirely of one week of classroom instruction. Being somewhat generous, management has also provided some "Booch books" and some "Alsys tapes" which the technical staff can look at, on their own time. (I am not knocking the quality or usefulness of these products, just their misuse.) 4. Since the only computer that has an Ada compiler on it is tied up with useful work, the one week of training they wish us to provide is a "hands-off" course. We may provide the students with some small "paper exercises," but we are being encouraged to forego any labs so that we can "cram as much of the language into the heads of the participants as possible." 5. The management is not open to any suggestions on how to improve the quality of the Ada training. It also happens that some other well-known Ada experts have attempted to enlighten the management, but have been rebuffed. The results of this project can be foretold quite easily.: - The programmers will find the Ada language to be "large, complex and confusing." The code they produce will be "AdaTRAN" at best. There will be a great deal of time spent trying to understand that "dumb reference manual." Ada books that emphasize syntax to the exclusion of software engineering will become prized possessions. Especially valuable will be books and references which treat Ada as "a superset of Pascal." - The programmers will find that the Ada development system is confusing to use. Since it is likely that the design will be in a constant state of revision, the specification parts of the Ada program units will change fairly often, necessitating frequent re-compilation and relinking. As the amount of code grows, the time spent re-compiling and relinking will quickly reach an intolerable level. Frequent references will be made to the large amount of object code produced, and its inefficient running speed. But after all, isn't that what one would expect from such a large language? - The programmers will find many features of the Ada language to be extremely bothersome. There will be frequent complaints about strong typing, private types (if they are used at all), the time for task rendezvouses, and those strange generic things. - More source code will be produced than for a comparable project written in FORTRAN or Pascal. The detractors of Ada will gleefully point to this as an expected result. - The project will be late, overbudget, and the software will not perform at anywhere near the original specifications. Looking for a scapegoat, management and the technical staff will grab the first inanimate object they can find (you guessed it -- Ada), and blame it for any shortcomings or project failures. The contracting office, being equally naive about Ada technology, will accept without question that Ada is the culprit. There will, of course, be many other problems, but let us now focus our attention on the root causes. The Ada language was designed by first identifying a number of desirable software engineering features (e.g., data abstraction, information hiding, and encapsulation), and then incorporating these features into a programming language. Since a good number of these concepts are foreign to most programmers and managers, it comes as no surprise that the concepts are often abused, if they are used at all. Many advocates of Ada technology have pushed the language, and ignored the software engineering. Yes, there have been some people within the DoD, and outside of the DoD, who have stressed software engineering, but their voices have been lost in the din. [Note the on-again, off-again funding for STARS.] Part of the blame lies at the feet of the DoD for not stressing software engineering strongly enough. Within the Ada Joint Program Office (AJPO) is the Ada Software Engineering and Education and Training (ASEET) group. Hopefully, one of ASEET's goals is to define minimal qualifications for an Ada software professional. This should be in addition to definitions for course content in an industry targeted Ada and software engineering training curriculum. Without any guidance, contractors are free to train (or not train) their technical staffs in any manner they choose. Further, contracting offices continue to have no idea as to what constitutes a qualified Ada professional. Of course, I am not going to let the contractor's management off the hook. Unfortunately, they learned a long time ago that software quality was little more than a buzzword. (Note: Much is known about software quality, including how to measure it. Sadly, this technology seems to be largely ignored.) They seem to get paid regardless of the "quality" of the software product. Is it any wonder why they view software as a necessary evil, and software engineering training as a useless luxury? So what if the software fails, so long as the hardware holds up. There is a one-word definition for learning: change. The hope behind Ada technology is that this change will be for the better. Until there is a greater recognition that Ada education and training is different, the change may not be what the proponents of the new technology have predicted. -- Ed Berard (301) 695-6960 -------