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!lll-lcc!styx!ames!ucbcad!ucbvax!ADA20.ISI.EDU!EBERARD From: EBERARD@ADA20.ISI.EDU (Edward V. Berard) Newsgroups: comp.lang.ada Subject: Ada Education and Training - Part 3 Message-ID: <8705032025.AA28248@ucbvax.Berkeley.EDU> Date: Sun, 3-May-87 15:23:12 EDT Article-I.D.: ucbvax.8705032025.AA28248 Posted: Sun May 3 15:23:12 1987 Date-Received: Sun, 3-May-87 21:54:48 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet List-Id: Recently, an instructor at one of the military academies told me how she had selected a book for an introductory Ada class. She had rejected Booch's book (Software Engineering With Ada) in favor of another text. It was not so much the text she had selected that bothered me, as it was her reason for rejecting Booch's book. "Booch takes too long to get to any code.", she said, "I want to see something like 'Hello World' real quick." [For those of you who have never programmed in C, or, more precisely, read Kernighan and Ritchie's book on the C programming language, the "Hello World" program is the first C program covered in many introductory C courses.] Kernighan and Ritchie (K&R) and Booch represent two very different views on teaching programming. K&R stresses the age old thinking which says that students of software must see, write, and execute code before anything else will be meaningful. Booch, on the other hand, stresses that students should know what they are doing before they attempt to write code. The K&R approach has its roots in software antiquity. Programming code is the "cocaine" of the software world. To many programmers and managers it is all that matters. While software is being designed, managers wait nervously and the programmers/coders wait impatiently. One the design document is finished, the "real work" can begin. With any luck the code which is produced may closely resemble what is described in the design documentation. To an outsider this infatuation with code seems strange. One hears from many sources that coding usually takes up only 10 to 15 percent of the software life-cycle. Why then do we focus so much attention on the syntax and semantics of the programming language? Several reasons come to mind: 1) Many of those who are already programmers and instructors believe strongly that, only if one is intimately familiar with code, can one fully understand the implications of any other part of the software life-cycle. 2) Some in the Ada community feel that the software engineering embodied in the Ada language will either be obvious to the neophytes or that through constant use of the Ada language, good software engineering concepts will be absorbed "via osmosis." 3) The concept of "instant gratification" is very much entrenched in modern software production. Sitting at their terminals in their offices or cubicles, programmers very much resemble "rats in Skinner boxes" who continually press a lever (the RETURN key) for constant reenforcement of their behavior. We are only now beginning to see tools which will allow us to "execute a design." 4) Software people have little faith in those concepts that come before the coding phase. "How can anyone possibly describe something which is not yet coded?", they reason. There is little emphasis on non-coding tasks in most commonly available training. It seems that most people have not understood the intentions of the U.S. Department of Defense (DoD) regarding the Ada effort. It is better engineered software that is desired, not merely "FORTRAN rewritten using the syntax and semantics of the Ada language." Too much emphasis has been placed on a tool (Ada) and not on the task (better software). Learning the details of the Ada language is at the "noise level" of most software projects. In fact, only a very small part of any "Ada education effort" needs to focus on the language itself. Concepts like configuration management, software design methodologies, data abstraction, concurrency, software testing, and project management must be an important part of any Ada training effort. Of course, there are many problems which must be solved, for example: - Contracting offices and project managers must recognize that the least significant part of any Ada training effort is the learning of the syntax and semantics of the language. Yes, it is important for programmers to learn the Ada language, but this is a trivial task compared to learning about modern software engineering. - Many of those who "teach" the Ada language are unfamiliar with the bulk of modern software engineering. For example, most may only have familiarity with functional decomposition approaches to software development. Few can name any references on software quality assurance. A surprising number cannot cite any studies which correlate coding style with debugging and testing efficiency. - When software engineering concepts are introduced into an Ada curriculum, it is often introduced in a very "watered down" form. This is so that those least prepared to develop quality software can maintain their positions -- managers *and* programmers. - There is still a widely-held belief that all that is involved with transitioning to Ada technology is a change of programming language. In reality, software development and maintenance practices will have to change, in-house and government software standards will be impacted, and business practices will change. [It is often those in the commercial sector who pick this up more readily than those in the defense sector. Further, those doing business applications using Ada technology more quickly see the impact of Ada technology than those doing scientific and engineering applications.] I would recommend that those charged with procuring Ada training, and those who determine the Ada qualifications of a potential contractor, look beyond mere coding ability. We must recognize that probably the greatest effort facing the advocates of Ada technology will be reformation of "code junkies." -- Ed Berard (301) 695-6960 -------