Re: Ada Education and Training - Part 3

Re: Ada Education and Training - Part 3

["LT Scott A. Norton, USN"]

In <1061@ico.UUCP>, hao!ico!rcd@ames.arpa (Dick Dunn) remarked,

"A somewhat worse confusion over teaching 'programming' (I would rather
 a less loaded term implying 'the complete process of constructing
 functioning software') immediately follows in Berard's article:"

I think the term he wants is "software engineering."

The hard part about teaching software engineering is that the need for
good engineering is not apparent at the classroom level.  The programs
that are written by individuals in an undergraduate software course are
less than a thousand lines.  They can be fully understood by one
person.  They do not undergo maintenance, and do not have to adapt to
changes in the environment, new hardware, or changed specifications.
They usually do not need to be robust, since they are not used by many
different users or under tight constraints.

There is certainly a skill called "Programming." Selecting algorithms
and data structures, making loops start and stop in the right places,
avoiding deadlocks; they are all part of programming.  But, when you
move to programs of over one million lines, the problems you face are
different.  Consistancy of the specification becomes more difficult.
Testing and debugging become more difficult ( some people say
impossible ) Training new staff is necessary as the work progresses.
As people leave the project, the knowledge they have must be passed
down to the remaining staff.  Its not a difference in scale, its a
difference in kind.

If you teach a course in programming, you expect people to come out of
it knowing how to write code.  Give them clear specifications and they
should be able to write modules that will meet the specs.  But writing
the specs, making the design decisions that determine the specs,
managing the programmers, designing tests, chasing down the
requirements that the system must meet, developing the documentation,
training the staff ( not how to code, but what the project is supposed
to do ) are part of the larger world of software engineering.  Its a
different dicipline, and can't be taught in a single course.

Ada is supposed to be a language that makes it easier to match modules
to specs, design tests, eliminate some tacit assumptions about
interfaces, and make code more readable to ease the problems of
bringing new people into a project or of doing maintenance.  Ada will
be successful if it improves not only coding, with its 15% of the load,
but also these other areas.

Programming : Software Engineering :: Word Processing : Writing a novel

When I was in fourth grade, I thought that higher math was being able
to do, like, really big long division problems.

LT Scott A. Norton, USN
Naval Postgraduate School
Monterey, CA 93943-5018
4526P@NavPGS.BITNET

Ada Education and Training - Part 3

[Edward V. Berard]

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
-------

Re: Ada Education and Training - Part 3

[Dick Dunn]

In one part of a rather lengthy article, Edward Berard takes on Kernighan
& Ritchie's _The_C_Programming_Language_.  He was talking about an
introductory text, so I'm not sure why he's picking on K&R, but he compares
their book with Booch:

> 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.

This is nothing more than an unthinking cheap attack on K&R.  It would seem
that Mr. Berard believes that K&R intends to teach programming simply
because he thinks it ought to do so.  However, if one manages to read as
far as the fourth paragraph of the Preface, one finds:
   "This book is not an introductory programming manual; it assumes some
   familiarity with basic programming concepts..."
Perhaps this was overlooked--after all, the Preface of a book may not be
good reading (unless you want to know the purpose of the book:-), so let's
have a look at the beginning of the "real" text.  If we read as far as page
1 of "Chapter 0" we find the following terms used without prior definition:
	programming language, operating system, text-processing, data-base,
	characters, character strings, addresses, storage allocation, heap,
	garbage collection, file-access methods, single-thread control
	flow, coroutines
I cannot, in my wildest dreams, imagine a normal neophyte being able to
read this section...hell; he won't even be able to parse some of the
sentences.

It is not the case that K&R present the "programming first, thinking later"
approach.  They have set out to provide a ready introduction and reference
for a particular programming language, and have succeeded in doing so.  K&R
have been set up.  "We want an introductory text.  We will label them an
introductory text.  Then we will demonstrate that they have failed."
[Hey, look, the shop manual for my car doesn't provide spiritual guidance
either.]

A somewhat worse confusion over teaching "programming" (I would rather a
less loaded term implying "the complete process of constructing functioning
software") immediately follows in Berard's article:
>...Booch, on the other hand,
> stresses that students should know what they are doing before they
> attempt to write code...

The reality of teaching lies in between the code-first approach (mis-
attributed to K&R, but it does exist elsewhere) and an approach which holds
off the code until the concepts are ingrained...because the fact of the
matter is that very few students can hang on to a substantial abstract
framework without something concrete to which they can relate it.

This is easy to observe in engineering and physical science undergraduate
curricula.  In the first year the students will be taking (let us say)
calculus and some substantial classical physics which requires calculus.
If the calculus courses follow a purely mathematical development of
functions, series, limits, etc. without adequate illustration of the
application of the concepts, the math instructors find that their students
are learning calculus better--and faster--in their physics courses.

(There are, of course, areas where it's hard to find the concrete materi-
al--for example, some concepts in topology--but the production of software
is not such an area.)

I'm not going to argue that the coding should come first.  That's not what
I'm saying and it's not even in the back of my mind.  It would be silly to
teach that way...but it's equally silly to think that you can (let alone
should) teach the concepts first and the programming later.  That's as
absurd (and antiquated) as the "waterfall model" of software lifecycle.
Consider it an overreaction to the "code first" approach.

It's all too simple:  Teach the two together.  Start developing the idea of a
programming language and a programming environment as you develop the first
concepts.  By the time you've got enough concepts to think about
interesting problems, you've also got enough concrete information to show
what an actual solution to a simple problem might look like.  And, I know
it's heresy in this group where so many people think that there is One True
Language, but you can use a couple of different programming languages to
illustrate examples--if you're careful, that can prevent students getting
hung up on one language.

(This is somewhat how I was first taught.  Perhaps the two languages were
not the best choices--FORTRAN and BASIC--but hey, that was twenty-odd years
ago, and it worked then.)

Another way to look at what I'm saying:  overemphasizing the coding is bad;
ignoring it is just as bad.  A little more from Berard's article:

> Programming code is the "cocaine" of the software world. To many
> programmers and managers it is all that matters...

Replace "cocaine" with "currency".  To many clients in the commercial
world, the code is [almost!] all that matters, because they aren't
interested in plans and studies except insofar as they help produce the end
result, and they don't believe that they can sell specs-by-the-pound.

The methodology is not the end product.

>...While software is
> being designed, managers wait nervously and the programmers/coders
> wait impatiently...

So get some good managers!  Sheeeesh!  As for the programmers/coders:  If
you divide your world into "those who design" and "those who implement the
design" you have created a caste system.  You have a social problem and
you cannot solve it by waving methodology about.

>...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...
This is a favorite litany of the methodology mavens...but if you think
about it, it's only reasonable.  Why is coding only 10-15%?  Well, one set
of reasons is that the code produced is so often late, inefficient, not
robust, inscrutable, unadaptable, and nonportable.  We spend the bulk of
our time screwing around with code that's already written because it was
lousy code in the first place...somehow I don't buy the idea that the
solution is to improve our ability to screw around with the code!  Couldn't
we try just a little to reduce the need to screw around with it?  If we had
done a good job with the 10-15% of the work, a lot of the 85-90% remaining
wouldn't have been necessary.

A couple more comments from Berard:

>    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...

Rubbish.  These aren't software people.

> 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). 

I agree with this in a perverse sense:  I do not understand it to be the
intent of DoD to produce better engineered software instead of a new
language.  If that is what they desired, why did the requirements used in
Ada development (the *man sequence) specify nitty details of syntax and
semantics instead of focusing on requirements?  Why did they spend a decade
screwing around with a programming language before getting on to the
environment?  Berard is quite right that "too much emphasis has been placed
on a tool...and not on the task..." - and the nature of the development of
Ada is the best example of that misplaced emphasis.
-- 
Dick Dunn    {hao,nbires,cbosgd}!ico!rcd  (NOT CSNET!)   (303)449-2870
   ...Nothing left to do but smile, smile, smile.