balcer@gypsy.siemens-rtl (Marc J Balcer) (02/16/89)
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
---------------------------------------------------------------------------rjh@cs.purdue.EDU (Bob Hathaway) (02/17/89)
>In the Spring '88 and Fall '88 semesters, I taught an "Ada >Programming Language" course at a small college. This was a rather Some good schools have a "Software Engineering with Ada" course or use Ada in their "Software Engineering" curriculum. Teaching a simple Ada programming course seems to be the problem. >"promoted" from computer operations. Not only were many unfamiliar >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?) A "Software Engineering" in the course title would have alerted them modern principles were being taught. > >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. > But many programmers are aware of all of this, I for one before learning Ada. How long before my first Ada program worked (with generics, Adts, dynamic arrays, arbitrary length strings, etc.) A few hours. I would change the above quotation to read: ADA is an incremental improvement in programming languages encompassing modern software engineering principles. >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." It depends on your background. After a few years of C and Modula programming and some independent reading on Ada, programming in Ada was an incredible delight from the start: greater power than C with the structure of Modula. I could see giving a one semester "Software Engineering With Ada" course by simply using some good references (Booch, Ada Letters, LRM) and by having a few experts available. >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? I suggest a short time with "Software Engineering with Ada" by Grady Booch is sufficient, possibly along with "Software Components With Ada" and the LRM. >2. How long does it take to properly re-educate a generic software > engineer into an Ada developer? Can the cost be recovered? This should depend on their previous experience and background. >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? Simple, offer a "Software Engineering with Ada" course like several universities. I think Ada is currently by far the best language for software engineering for both teaching and practice. > >4. What qualifications (read "experience working on Ada projects") > should be required for those teaching Ada? > I know of one qualification which may be underemphasized: a genuine desire to program in state of the art languages using state of the art methodologies. I'm sure everyone on all the Ada committes could pass this test with ease... > >5. Can some of these efforts lead to an expansion of the Ada base > beyond DoD and DoD contractors into other industries? I certainly hope so. Since Ada offers the most modern programming constructs and methodology I see little reason to use anything else. With conferences discussing future enhancements I expect the situation to stay that way, since other groups (such as the Modula-3 group) will keep the leading edge in state of the art programming language design moving. Bob Hathaway rjh@purdue.edu
gore@eecs.nwu.edu (Jacob Gore) (02/17/89)
/ comp.lang.ada / balcer@gypsy.siemens-rtl (Marc J Balcer) / Feb 15, 1989 / > 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? Very frequently, when I try to explain to people that there is a big problem with the software-related part of the CS curriculum at Northwestern, I am asked, "Well, what language would you teach?" Wrong question. Programming languages are tools. Teaching Ada for the sake of teaching Ada is a waste of everybody's time. Most (all, hopefully :-) of the people taking courses here are literate; they can read on their own enough Ada books and manuals to learn anything from how to write a BASIC program in Ada syntax, to the most intricate details of the language. Ada IS just another language. What is different about it is what was meant to be expressed in it. What needs to be taught are the skills, methodologies, techniques, approaches... whatever else you wish to call them. The language used in a course is there to help illustrate the concepts and to experiment with their implementations. In this light, the question of what (if anything) to teach (or re-teach) before teaching Ada turns into the question of whether or not Ada is the first language to use to illustrate such concepts. I think it can be, but it doesn't have to be (in fact, it may not be my first choice). Ada can be taught either concurrently with teaching the concepts, using it to illustrate them, or, if another language is used to present the concepts, after those concepts are already presented. In the latter case, a "quick course" in Ada will be sufficient to let the students get on with their work. Of course, real proficiency in using Ada can only come with experience. Jacob Gore Gore@EECS.NWU.Edu Northwestern Univ., EECS Dept. {oddjob,gargoyle,att}!nucsrl!gore
billwolf@hubcap.clemson.edu (William Thomas Wolfe,2847,) (02/18/89)
From article <6660@siemens.UUCP>, by balcer@gypsy.siemens-rtl (Marc J Balcer): > The official prerequisites for the [rather popular Ada] 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. [...] 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?) The problem is with the prerequisites, I think. Another poster (Bob Hathaway) recently said that he had no trouble with Ada, etc., while posting from purdue.edu; this indicates that the people who are coming up from college TODAY are being properly trained in software engineering concepts. The problem is that vast numbers of people graduated from college back in the days when hacking was the dominant paradigm. These people evidently did not absorb basic concepts of professionalism, such as "A professional maintains membership in professional organizations such as the ACM, and must continuously strive to stay abreast of both the state of the science and the state of the technology". Ada cannot be taught in isolation. Software engineering must be either a prerequisite or a corequisite. Data Structures should also be a prerequisite, so the students will understand what an ADT is. Specify these topics as unconditionally required for admission, and let the Registrar do the enforcement. This should eliminate such problems. Bill Wolfe, wtwolfe@hubcap.clemson.edu
beal@mussel.cis.ohio-state.edu (Alan Beal) (02/27/89)
In article <6660@siemens.UUCP> balcer@gypsy.siemens.com (Marc J Balcer) writes: >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?) This is a common problem in the government. The majority of the government's software is in COBOL, and a good many of its programmers know nothing about C, PASCAL, etc. The major reason for this is that the government can not recruit people with any type of CS degree. How many CS majors out there would be willing to start at $14,000? But a lot of secretaries, computer operators, and low level managers are willing to become 'programmers' in order to reap the riches of computer industry. I worked for the government for awhile and everything was done in COBOL with a little systems work done in Algol(Burroughs shop). Management kept saying that the DOD had mandated ADA as a programming language of the future but from what I saw, only about 10% of the programmers would be able to comprehend ADA or would be willing to try. Personally, I don't see the government completely switching from COBOL to ADA because of the expense of conversion, cost of training, and resistance to change. However, the trend in the government is to contract out this type of work, so who knows. -=- Alan Beal The Ohio State University Department of Computer and Information Science beal@cis.ohio-state.edu {pyramid,killer}!osu-cis!cis.ohio-state.edu!beal