EBERARD@ADA20.ISI.EDU (Edward V. Berard) (05/07/87)
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
-------