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 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 2 Message-ID: <8705011551.AA17415@ucbvax.Berkeley.EDU> Date: Fri, 1-May-87 08:20:10 EDT Article-I.D.: ucbvax.8705011551.AA17415 Posted: Fri May 1 08:20:10 1987 Date-Received: Sun, 3-May-87 00:42:02 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet List-Id: Some years ago, when I began offering one of the first hands-on Ada courses, I invited some of the members of the Ada Joint Program Office (AJPO) to sit in on the course. Those that accepted my proposition gave me some interesting feedback. It seem to the AJPO folks that my Ada courses were severely lacking in software engineering. I was puzzled. I had incorporated sections on structured programming and coding style into my notes. What more did they want? I now know that my first attempt at an Ada course was little more than a glorified Pascal seminar. I gave short coding examples for labs, and treated packages, tasks, and generics as "advanced features." There was little discussion of abstraction, information hiding, and encapsulation. The message eventually got through to me that a "syntax course" was a "no no," and that software engineering was much more than just structured programming. However, there was still a major problem. As you know,the software community, as a whole, is initially not very receptive to software engineering concepts. Managers and programmers alike are obsessed with code. The sooner you can get down to coding the more comfortable they feel. Software engineering is mockingly referred to as "software religion" by many. Management continually assures me that there may be time to learn something other than coding "later." Let me assure you that it takes a great deal of persuasion ("singing and dancing," cajoling) to get management and the technical staff to consider software engineering as an important part of Ada training. Fortunately, I have two things going for me. First, most software professionals want to do a good job. If I can show them a way which will make their software products better, and justify my reasoning, they will generally accept the idea. Second, software types are extremely goal oriented. Given proper goals, they will work hard to achieve them. Unfortunately, there are those Ada trainers who are not as persuasive as myself. They are easily bullied by their client's management and technical staff into giving syntax-only courses. Since their clients are often blissfully ignorant of the impact of poor software engineering, especially on an Ada project, the clients often see no immediate benefit from the incorporation of software engineering technology into an Ada training course. In a perfect world, software contractors would want to do everything in their power to produce a quality product. Unfortunately, many DoD contractors seem to be primarily driven by money and DoD regulations which must be adhered to to ensure the continued flow of money. (Don't get me wrong. I am very much a capitalist.) This implies that one way to improve the current state of Ada education and training might be some gentle prodding by the DoD. Say, in the form of some recommendations from the Ada Software Engineering and Education and Training (ASEET) group. Two months ago, I received a message from Doug Bryan who, among other things, teaches an Ada course at Stanford University. I think you will find his message to be of general interest. ------------------- Message Follows ------------------------ I tried something new (and costly) with my Stanford class this year. Usually I teach abstraction -> misc. s/w eng -> OOD -> reuse -> the details of Ada This year I tried reversing it since "the powers above" wanted it to be more of a programming class and less of a Software Engineering class. So, I taught the details of Ada -> abstraction -> OOD (OOx) -> reuse I'm now grading some of the final projects and realizing this was a real mistake. Their code is terrible and it's my fault. Their packages are best classified as "collections of stuff"; Private types, generic formal parameters, and decent use of attributes are practically non-existent; most every subprogram is a procedure, all parameters of which are mode in out; ... the list goes on and on. It was costly, but I have seen first hand empirical evidence of what the Ada community has been telling itself (and others) for years: Ada without a software engineering foundation is MIL-STD Pascal. live and learn... ------------------ End of Message -------------------- -- Ed Berard (301) 695-6960 -------