EBERARD@USC-ISIF.ARPA (Edward V. Berard) (11/29/85)
As chairperson of the SIGAda Issues Working Group (a working group
within the SIGAda Education Committee) I have been charged with creating
a "Strawman" document on "Professionalism for Ada Software Personnel."
This document must be in a form for publication by January 1986. It will
be discussed at the February 1986 Sigada meeting in Los Angeles. This
document must address management as well as technical personnel.
At the recently held SIGAda meeting in Boston, this topic was discussed
at a BOF session. At that time, the participants suggested a number of
topics for inclusion in the document. These topics are listed below. If
you have any comments on this effort, or if you wish to participate in
its preparation, please contact me ASAP.
The topics are:
1. A Professional License Exam
2. Responsibility
3. Code of Ethics
4. Accountability
5. Minimal Knowledge Base
6. Job Titles/Categories
7. Things to Change
8. Strategies for Change
9. Metrics
10. Legal Issues
11. Internship
12. Continuing Education
13. Political Issues
14. Public Relations
15. Ownership
16. Professional Model
17. Peer Review
18. Censure and Appeal
19. Best Programming Practice
20. Transition Strategy
21. Major Professional Society
22. Regulatory Board
-- Edward V. Berard
EVB Software Engineering, Inc.
451 Hungerford Drive, Suite 100
Rockville, Maryland 20850
Phone (301) 251 - 1626
MIL-Net EBerard@ISIF
-------VaughanW@HI-MULTICS.ARPA (12/02/85)
I think it's downright awful that the spectre of protectionism has
finally arrived at SIGAda. Of course, it might have been expected,
since Ada is a Government (with a VERY BIG G) project.
From the list of topics, it seems you intend to nominate yourselves as
an Establishment, with rights to (a) prevent others from entering the
clique, and (b) prescribe the Proper Way To Do Ada Programming.
I would find this silly, but I fear that with the Government behind you,
you may well be able to achieve this atrocity.
I sincerely hope you fail.
Bill VaughanBakin@MIT-MULTICS.ARPA ("David S. Bakin") (12/02/85)
[OK I know this isn't the proper forum but ... ] Has anyone heard of some sort of joint ACM/IEEE committee on Computing Sciences Accreditation? 1) Where is the proper place to look for information about it? 2) Is anyone participating/following up on this committee? 3) Does anyone know how such a committee would affect me, a working "software engineer"? Private replys to me, including I hope, someone to tell me what ARPA mailing list is discussing this stuff -- Dave (Bakin -at mit-multics)
dgary@ecsvax.UUCP (D Gary Grady) (12/02/85)
An article by James Fallows in the December _Atlantic_ might be of
interest to those debating the merits of a system for licensing
programmers. Fallows notes that creating a closed "guild" system often
leads to an enforced mediocrity that puts emphasis on input (years of
education, passing an entrance exam, perhaps some "continuing
education" requirement) rather than output (being able to do the job).
There is some justification for licensing those serving the general
public when the public would otherwise have trouble evaluating
qualifications and when a mistake could be disastrous, as in law and
medicine. I am prepared to argue that the current licensing schemes in
those professions are better than nothing, but not much. In the case of
programmers, however, those hiring are in a better position to judge
individual qualifications than the public. Professional licenses for
programmers? I say it's spinach, and to hell with it.
--
D Gary Grady
Duke U Comp Center, Durham, NC 27706
(919) 684-3695
USENET: {seismo,decvax,ihnp4,akgua,etc.}!mcnc!ecsvax!dgaryrcd@opus.UUCP (Dick Dunn) (12/03/85)
I only follow net.lang.ada as a matter of curiousity and keeping tabs on what the folks here are up to. The implications of the parent article are pretty appalling; I'm glad the reaction has been generally negative. I'll add a few cheap shots of my own: > ...As chairperson of the SIGAda Issues Working Group (a working group > within the SIGAda Education Committee) I have been charged with creating > a "Strawman" document on "Professionalism for Ada Software Personnel."... What on earth can possibly be meant by "Ada Software Personnel"?!?! Are we so specialized? (Or is Ada so complex or so bad that you must be an Ada software person iff you are no other sort of software person?:-) To me, "Ada Software Personnel" has the same tenor as "Sink Personnel"/"Bathtub Personnel"/"Toilet Personnel" distinctions when we're talking about plumbers. If you can only program in one language, you can't program yet. (Whew! There, I've said it; let the flames begin.) Lordy! Ada is just another tired participant in the 25+ year progression of procedure-oriented/imperative/algorithmic languages. There's no sin in a language being in that category, but you can only impute so much importance to the 327th set of miniscule refinements of an idea. Would it be too much to ask for a set of criteria, if they're really needed, for "Professionalism for Programmers"? > This document must be in a form for publication by January 1986. It will > be discussed at the February 1986 Sigada meeting in Los Angeles. This > document must address management as well as technical personnel. But what is the problem? It seems that someone is rushing off to create documents (which are the wombs in which committees are conceived) to be busy about some matter which has yet to be stated. Perhaps I am being too kind. Perhaps there is an epidemic of unprofessional behavior which confines itself to Ada programmers...oops, excuse me, software personnel. Maybe the Ada world has problems that the rest of us don't? (If it does, I would guess it to be the overambitious exploration of non-issues:-) But what are the issues of concern to these Ada software personnel? > 1. A Professional License Exam By all means...and let's start licensing mechanics--separate licenses for each of socket, hammer, impact wrench, screwdrivers (with optional specialization in Phillips, flat, and for the experts, Torx). > 2. Responsibility > 3. Code of Ethics > 4. Accountability These sound like good things to be considered as Ada-specific! (Actually, I could be serious here--to the extent that the Ada community is visibly more tempted by the prospect of gouging the US government out of big $$$ than any other language-oriented community...but that is not an aspect that's likely to be of interest to the paper-generators.) > 6. Job Titles/Categories What do the rest of you think? Is it different than the rest of the industry? > 11. Internship FOR A SINGLE SILLY LANGUAGE?!?!?! > 12. Continuing Education ditto > 16. Professional Model > 17. Peer Review > 18. Censure and Appeal > 19. Best Programming Practice Don't you know how to deal with these matters? Do it one-on-one; work with people. There's nothing you can cast into rules and procedures that can't be done better and faster by clear-thinking individuals acting on their own judgment. > 20. Transition Strategy From what to what? (I have the feeling that there are still people who think that Ada is the single language of the future and that all we have to do is convert to it. If there are, I'd like to know (1) what they're smoking and (2) where I can get some--a small quantity only.:-) > 21. Major Professional Society ...some of which have heartily rejected Ada (in response to the way the perpetrators of Ada have rejected them). If the kids won't let you play, you can buy your own football, huh? > 22. Regulatory Board ooooof. bureaucracy. No more to say. -- Dick Dunn {hao,ucbvax,allegra}!nbires!rcd (303)444-5710 x3086 ...Reality? Gad, that's worse than puberty!
dma@ssc-vax.UUCP (Dennis Anderson) (12/04/85)
We already have a military standard CPU architecture (Mil-Std-1750A), and a military standard language (Ada). Is it now intended to create military standard programmers? One of the reasons for the development of Ada was the reduction of the life-cycle costs of software. It isn't going to reduce costs if you seek to limit the number of programmers allowed to write it. >There is some justification for licensing those serving the general >public when the public would otherwise have trouble evaluating >qualifications and when a mistake could be disastrous, as in law and >medicine. I am prepared to argue that the current licensing schemes in >those professions are better than nothing, but not much. In the case of >programmers, however, those hiring are in a better position to judge >individual qualifications than the public. Professional licenses for >programmers? I say it's spinach, and to hell with it. >-- >D Gary Grady >Duke U Comp Center, Durham, NC 27706 >(919) 684-3695 >USENET: {seismo,decvax,ihnp4,akgua,etc.}!mcnc!ecsvax!dgary Absolutely right. Professionalism in programming is good. A legally enforced standard of professionalism is not. We should all work to do away with the effort in this direction before it gets out of control. Dennis Anderson @ Boeing Aerospace
beth@gymble.UUCP (Beth Katz) (12/05/85)
I'm not sure I want to jump into this fray, but I'm very much pro-Ada and anti-"Ada Professionalism Document". First of all, as others have mentioned, people using the Ada language should not have a separate code of ethics. I have difficulties with the professionalism movement alone. What you consider important for a software professional may be contrary to what I feel is important. Focus on ethics and certification if you must, but leave Ada and SIGAda alone. Secondly, we just don't know how Ada *should* be used. We don't have enough experience with it. We don't know which design methodologies are appropriate for particular applications. We don't know how to train people to use Ada as a software engineering language and really use the appropriate concepts that are supported by Ada. Various people in research, government, and industry are looking at these questions. Until we really know what is happening with Ada use, please don't try to "certify Ada software personnel." ----------------------------------------------------------------------- Arpa: beth@mimsy.umd.edu Elizabeth E. Katz UUCP: ...!seismo!umcp-cs!beth Dept. of Computer Science CSnet: beth@umcp-cs University of Maryland Of course these opinions are my own. Valid data supporting conflicting views readily received and discussed. I'd love to discuss how you are using and measuring your use of Ada.
mack@mlokai.DEC (12/06/85)
The problem I have with the document (and it seems, the problem that
several respondants have with the document):
Its existence implies that ADA is so different from other lang-
uages that it completely redefines the standard of software
professionalism.
ADA is different from other languages in a number of significant ways,
the most important being the possibility of directly implementing both
abstract data structures, multi-tasking, and (at least theoretically)
true parallel processing. Now, object-oriented, "architecturally pure"
programming is not only possible, but directly supported by a language.
If we understood object-oriented programming precisely (not just gener-
ally), then a document could be put together to define precisely what
object-oriented programming is. If this were considered the only right
way to program, we might even dare to call it a software design standard.
However, extending it into a complete model of software professionalism
is ridiculous. (Even this paragraph has a couple of big if's).
I suppose I am biased by my own situation. While many of the people in
this newsgroup are doing work related to the military, and are therefore in
some way a "captive audience" of ADA :-), I am using it in a non-military
(commercial/engineering) setting, and trying to show that its benefits
outweigh the costs of learning it and using it. The people I am working
with are using all sorts of languages: BASIC, BLISS, C, FORTRAN, PL/1,
PASCAL, you name it. A document like this is likely to make it harder
for me to do. ("What's this? Is everybody going to have to learn to
program all over again? No thank you!")
Ralph Mack
Applied Technology Software/Systems
Digital Equipment Corp.
"Any ideas expressed here are just my jaw working overtime, and
may not represent rational thought, much less the point of view
of Digital Equipment Corporation..."savage@ssc-vax.UUCP (Lowell Savage) (12/12/85)
> > > The problem I have with the document (and it seems, the problem that > several respondants have with the document): > > Its existence implies that ADA is so different from other lang- > uages that it completely redefines the standard of software > professionalism. > > ADA is different from other languages in a number of significant ways, > the most important being the possibility of directly implementing both > abstract data structures, multi-tasking, and (at least theoretically) > true parallel processing. Now, object-oriented, "architecturally pure" > programming is not only possible, but directly supported by a language. > > ... > However, extending it into a complete model of software professionalism > is ridiculous. (Even this paragraph has a couple of big if's). > > Ralph Mack > Applied Technology Software/Systems > Digital Equipment Corp. > > "Any ideas expressed here are just my jaw working overtime, and > may not represent rational thought, much less the point of view > of Digital Equipment Corporation..." I think that Ralph has hit one of the nails on the head. I think that before this thing goes any further, we should find out more about the root of this matter. It may be just some joke. (Perhaps perpetrated by the same person(s) that ran the article on making C functions pass parameters by address rather than by value in the Cray implementation. That article generated a whole lot of net traffic until the original poster(s) fessed up just so he/she/they could read their beloved net.lang.c newsgroup again.) If this is not a joke, then I can personally only imagine that some fevered DoD person with nothing else to do dreamed this up after celebrating something a lot too much. First of all, the idea of any "technical requirements" seems ludicrous to me. If a text file (or some set of text files) is compiled by a verified Ada compiler, then it is an Ada program program whether it is programmed by John Barnes or by a rotton banana dropped on a keyboard. Now if the DoD wants to make sure that the programmers working on its projects are competent, (so: competent programmers + Ada => correct code) it should probably make the the same type of contractual requirements of its contractors that it does to assure that other types of engineers are competent in their fields. Devising some sort of Professional Software Engineering license may be the way to go. (Actually, revamping the whole Professional Engineering licensing system may be the way to go, from what I understand--which is precious little, so never mind.) However, focusing the licensing on Ada is short-sighted and narrow-minded. (Unless, of course, the DoD intends to either keep Ada as the DoD standard for all eternity, or always revamp Ada and keep calling it Ada even when SW technology advances make the new version completely unlike the what people originally got licensed on....). Second, the idea of using a "code of ethics" to ensure "professional conduct" on the part of Ada programmers (and in particular those working on DoD projects) seems to be another idea straight out of the Department of Redundancy. If you want to make sure that the engineers working on a contract are not going to screw the govern- ment over, you make the project classified and force the company to pay for background checks to clear everyone involved in the project for working at that classification level, and you use the laws already in place (such as those regarding the travel of such persons overseas) to make it less likely that anyone will try to mess up the "security of the United States". In short, professional licenses for SW Engineers may be a good idea, but not strictly in the context of Ada. If it is strictly in the context of Ada, it will basically be treated as a joke by both the companies that hire such people and by the people that get the license. So why do I bother with all of the above?? Simple, I think that my tax dollars are at stake here. Maybe only a few cents a year, but it all adds up!! Some goof-ball has the wrong idea, and is going to SPEND **MY** MONEY proving it wrong! Lowell Savage I don't yet get paid enough for my work, so my employer has no right to my opinions. Oh yeah, Ada is a trademark of the U.S. DoD....