comp.lang.ada
 help / color / mirror / Atom feed
* Ada, "Software Fantasyland," and Quick Courses
@ 1989-02-15 18:54 Marc J Balcer
  1989-02-16 21:08 ` Bob Hathaway
                   ` (3 more replies)
  0 siblings, 4 replies; 6+ messages in thread
From: Marc J Balcer @ 1989-02-15 18:54 UTC (permalink / raw)


Two articles today caught my interest, giving me an opportunity to
let loose some frustrations. 

In the Spring '88 and Fall '88 semesters, I taught an "Ada
Programming Language" course at a small college.  This was a rather
popular course; as one student put it, "I can put Ada on my resume.  
Now I can get a job with <generic DoD contractor>."

The official prerequisites for the course included only one semester
of Pascal programming.  I told the students that they really needed
CS2 (Advanced Pascal) and Data Structures as well; I did not intend
to spend 3 lectures explaining what arrays, records, and pointers
were.  Nor did I want students who thought a "big program" was
anything over 50 lines long.

When I first taught the course, a local DoD contractor sent about 15
of its people to "take the course and learn Ada."  I had been assured
that all of these people were "experienced programmers and software
managers."  However I soon learned that the depth of experience for
most of them was assembly languages and CMS-2 on a single project.
Most had learned programming while in the service, or had been
"promoted" from computer operations.  Not only were many unfamilar
with high-level languages, I had to justify structured programming!
Strong typing was something to be defeated.  (Was I naive for making
assumptions about their background?)

(And the Army still recruits people by promising to teach them
"computer programming.")

Not only that, but the "Ada myths" were rampant.  Example:  "We can't
use Ada because you can't AND and OR bit fields (integers)."  I
asked, "What kind of problem are you trying to solve?"  (The problem
they had could be solved easily with a record type and a rep clause.)
However, they had spent their entire careers focused on the
machine-level rather than the problem-level.

But the worst part is that few, if any, of the software managers had
any background in "modern software engineering principles" (other
than contempt for the people who practiced them).  Ed Berard is
right:  nearly all of them felt forced to use Ada.  For them, the
programming assignments were sheer torture (many hadn't coded
anything in years).  There was little appreciation for style and
structure---all that mattered was that the program worked on the test
data.

These people seemed to be learning Ada in a vacuum.  Most had never
heard of ACM, none were aware of SIGADA, SEI, STARS, APSE, and such.
They were unaware of any "Ada mentors" in their company.  Upper
management seemed to believe that they could simply buy a compiler,
throw copies of the LRM at the engineers, and expect them to be
coding Ada the next week.  After all, it's "just another language,
right?"

ADA IS NOT "JUST ANOTHER LANGUAGE."

Many of the features of Ada make no sense to a programmer who is
unaware of, and not motivated toward the concepts of structured
programming, modularity, information hiding, object-oriented design,
....  I could go on and on.  

There seems to be no end to the desire for "quick Ada" courses.
(Maybe I should have left it misspelled -- "quack Ada.")  However,
there's a BIG difference between exposure to the language and
competence in it.  Although I had learned structured programming (in
Pascal) from the beginning, and had practiced (and taught) "good
software engineering principles" for 7 years, it took two more years
of working full-time on an Ada project to develop a minimal
competence in the language---to learn "how to do it the Ada way."

Stricter qualifications are needed, but I object to the establishment
of a specific "competency exam" for software engineers.  (No one
suggested it, but...)  The field is still too dynamic.  Too much is
changing.  To establish a fixed criteria would lock in certain
practices and make them very difficult to change.  At the worst, any
examination would be little more than a trivia quiz.

I'll conclude with a few questions:

1.  How much re-educating of DoD software enginners is necessary
    BEFORE teaching Ada?  In other words, should we be teaching
    software engineering fundamentals first?  What's the most
    effective way to do this?

2.  How long does it take to properly re-educate a generic software
    engineer into an Ada developer?  Can the cost be recovered?

3.  Where does Ada fit into the college curriculum?  How can we
    educate students in good software engineering, not just give them
    "Ada" on their resumes?

4.  What qualifications (read "experience working on Ada projects")
    should be required for those teaching Ada?

5.  Can some of these efforts lead to an expansion of the Ada base
    beyond DoD and DoD contractors into other industries?
---------------------------------------------------------------------------
Marc J. Balcer
[balcer@gypsy.siemens.com]
Siemens Research Center, 755 College Road East, Princeton, NJ 08540
(609) 734-6531
---------------------------------------------------------------------------

^ permalink raw reply	[flat|nested] 6+ messages in thread
end of thread, other threads:[~1989-02-26 20:39 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1989-02-15 18:54 Ada, "Software Fantasyland," and Quick Courses Marc J Balcer
1989-02-16 21:08 ` Bob Hathaway
1989-02-17  3:29 ` Jacob Gore
1989-02-17 16:04 ` William Thomas Wolfe,2847,
1989-02-26 18:02 ` Alan Beal
1989-02-26 20:39   ` "Software Fantasyland," and Government Agencies Devon Tuck

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox