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!rutgers!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 4 Message-ID: <8705071311.AA16317@ucbvax.Berkeley.EDU> Date: Thu, 7-May-87 07:27:38 EDT Article-I.D.: ucbvax.8705071311.AA16317 Posted: Thu May 7 07:27:38 1987 Date-Received: Sat, 9-May-87 03:53:01 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet List-Id: You might say that this is a discussion of the "dynamics of Ada technology education." First, a few simple ground rules: 1) Education is different from training. To be crude about it, training is what you do with dogs, education is what you do with people. Seriously, training of people works best with material which is extremely simple and has well-defined ("black and white") rules. If something can be done by rote, then training is appropriate. Education of people is what is required when the rules and guidelines of a technology do not easily lend themselves to simplistic ("black and white") interpretations. There may be many possible answers to a single problem, and the identification of a specific acceptable set of solutions will change depending on the particular constraints you put on the problem. 2) A consequence of the above is that education may require certain skills and aptitudes that are not necessary for training. For example, while training might be appropriate for an electronics technician, education is what is required for an electronics engineer (here, an electronics engineer is taken to mean someone with at least a bachelors degree in electronics engineering). 3) A one-word definition for learning is: change. Both education and training require change. Often this change is not limited to the mental state of the individual being educated or trained, but also extends to the working environment of that individual. 4) Two very different paths are taken with the activities associated with training and education. Since training is appropriate for situations requiring little original human thought or judgment, the activities for which a human is trained can often be easily automated. (Consider, for example, the training of a welder on an assembly line, and the eventual replacement of that welder by robots.) Activities requiring education, on the other hand, usually involve many constantly varying pieces of information. The tools, techniques, and methods used to handle situations for which education is appropriate, may themselves be quite complex. (Consider, for example the use of mathematics to calculate the dynamics of the liquid fuel in a rocket during take-off.) Typically, situations requiring education lend themselves to being assisted by, but not replaced by, automation. There are many players in the dynamics of Ada technology education. In the case of U.S. Department of Defense (DoD) related efforts, the player farthest removed from the actual engineering of the Ada software is the customer, i.e., the DoD. These people must be educated to the point where they realize that training is NOT appropriate for Ada technology, but that education is required. Many of us have been denying the truth for years. We may have felt that software production and maintenance required training, not education. This is not true. In fact, we should have been educating our technical and managerial personnel in software engineering technology all along. The DoD's Ada effort is the collection agent, and it is here to collect all our past due software engineering education. This is what makes Ada technology education so difficult. Ada educators must not only teach the syntax and semantics of Ada, but they must also educate their students in software engineering technology. Closer to home, we have the management of the organization requiring the Ada technology education. Management must understand that they must help and encourage Ada technology education. They must provide the tools and people necessary for good Ada technology education. They must let the people they manage know that they take software seriously. It is management which can make or break an Ada technology education effort. Two contrasting examples are necessary here. At Magnavox in Ft. Wayne, Indiana, Management was seriously committed to the concept of Ada technology education: - Management required themselves to go through the same training that they put their technical staff through. This began to make them aware of what their technical could expect, and gave management a chance to ask questions in context. - Management had themselves trained first. This gave them the lead time to begin preparing themselves and their staff for the changes which were to come. - Training was from 7:30 A.M. to 4:30 P.M. every day with one-half hour off for lunch. The class participants were already working on their labs when the instructor arrived, and continued to work after the instructor left for the day. - No one was allowed to disturb the class. Unless it was a truly life-and-death matter, the best that anyone could do was to place a note on the classroom door if they wanted to get the attention of a class participant. - Management made sure that tools (e.g., an Ada compiler) were procured as early as possible, and that all that needed to, had access to the tools. Another organization (unfortunately, a well-known name in the Ada business) had management which did about everything they could do to prevent Ada education from happening: - They delayed any kind of Ada technology education until shortly before the coding was to start on the project. - They did not allow their technical staff to participate in classroom activities on a regular basis. The number of students in the class room varied from zero to about seven. (That's right, one day the instructor showed up, and there were no students in the class for most of the day.) - Management themselves kept well away from the classroom. - During the first course which required the use of an Ada compiler, the labs were delayed because the compiler was not even installed until the middle of the week. Even when the compiler was installed, it was installed so badly that it was all but unusable. In summary, management can either aid the dynamics of Ada technology education, or ensure the failure of Ada technology transfer. Inside the classroom, we have another set of dynamics, specifically the relationship between the instructor and the students. A good instructor knows that "education is a two-way street." The instructor must listen to the students and be sensitive to their needs. The instructor must make reasonable attempts to reach most, if not all of the people in the class. In industry (as opposed to academia), at least fifty percent of an instructor's job is leadership. An instructor must both listen to and understand the needs of the people he or she is charged with educating. However, it is the instructor who must motivate and lead the class. This is especially crucial in the case of Ada technology education. Many students arrive at their first Ada class fully expecting a syntax course. It takes work and a good deal of persuasion to foster a desire for software engineering as opposed to just learning the syntax of "just another language." Some Ada instructors are bullied by their students into providing a syntax-only course. (I remember advising one of these instructors to "get up early on Sunday morning and watch some of the TV evangelists for inspiration.") Just getting into the classroom can be a challenge. The perspective instructor must successfully persuade management that software engineering is a good thing, and is more important than Ada syntax. The instructor must not insult the intelligence of his or her students. Students are fully capable of learning about software engineering on the very first day of instruction. The belief that students must know code syntax before software engineering will make any sense is just plain wrong. Software engineering instructors have two things going for them. First, software professionals are very "goal oriented." Once proper goals are set perspective software engineers will strive for them. Second, most software engineers want to to the best job they possible can. Showing how each piece of software engineering technology aids in achieving this goal helps the Ada technology instructor get the job done. If, however, the instructor does not have a firm grasp of software engineering technology, he or she cannot hope to convey the technology to the students. Merely saying the words "abstraction" and "information hiding" a few times does not merit being called a software engineering approach. Software engineering is an enormous discipline encompassing methodologies, metrics, mathematics, computer science, engineering disciplines, analytical and logical thinking, communication skills, and other factors. The classroom dynamics I have just described also work in academia. Having taught in college classrooms for regular college courses myself, I can attest that from the first day in their freshmen classes, college students are fully capable of understanding engineering disciplines. Consider the freshman who is an electronics engineering student. He or she may have entered college thinking that electronics engineering was little more than "building Heath kits." However, engineering students soon find themselves in classes on complex analysis, differential equations, physics, chemistry, statics, dynamics, strength of materials, English, history, and other disciplines. The same kind of thinking holds for software engineering students. They may enter a university thinking that software engineering is "glorified hacking," but they are just as capable as the electronics engineering student of learning the full discipline, not just the least significant part (i.e., coding). -- Ed Berard (301) 695-6960 -------