EBERARD@USC-ECLB.ARPA (Edward V. Berard) (09/11/85)
I have some (strangely enough) Ada-related professionalism questions.
I would suggest that you reply directly to me on these, and I will
post the results. As usual, flames are always welcome.
1) From a contracting office's point-of-view: How does one
determine a contractor's Ada capability? Since this capability
is largely a function of the capabilities of the individuals
the potential contractor intends to place on the project if the
contract is awarded, how does a contracting office assess the
Ada capabilities of these individuals?
2) From a manager's point-of-view: How does one select managers
and programmers for an Ada project? What specific
qualifications should they have?
3) From a programmer's or a manager's point-of-view: How do I know
where I stand in terms of my Ada capabilities? Am I improving,
or getting worse?
-- Ed Berard
EBerard at ECLB
(301) 251 - 1626
[Last week there were some problems on the net. Some of you may have
already seen this message.]
-------alden@spp1.UUCP (09/11/85)
Ed, This is a very snobbish set of questions. First of all I want to state up front that I am an advocate of Ada and support its use as a language for development of many applications. I call your set of questions snobbish because you are implying that Ada is some how above other programming languages. Ada is just a programming language, like any other programming language. It takes an input file of programmmed code in non machine language and generates an output file which the operating system can load into the machines memory for execution. Amazing ... even fortran ... or god forbid assembly language does this. Your questions about professionalism specific for Ada suggest that there be some separate criteria to chose Ada programmers. What suggests that Ada is special. Currently the only thing that sets Ada out is the fact that its a new language and not many people have used it yet. I have worked with many people who have learned to effectively use Ada on the job in a few months. Granted their code is not the most sophisticated code, but then again most applications don't need to use tricky aspects of the language to get hte job done ... because the job could have been done in fortran and since Ada can do what fortran does (at least!) and fortran does not have the power of Ada then presumably you can expect simple aspects of Ada to be effective. I do suggest that we use Ada to code like fortran... everyone is trying to avoid this. The major point is that if someone codes a program in Ada and the program is sound (i.e. works well), and organized accourding to the packaging constructs supplied by Ada then no one should have any complaints. What and how programmers organize their programmers should be controlled by the project manager of the project in question. It is the job of the project manager to set such coding standards .. this is true for projects coded in any language even fortran and assembly. In addition, your suggestions for guidelines suggest that you are not interested in bringing Ada into wide use by as many programmers as possible. For Ada to become a real standard, and for its use to be enforced by DoD contracts, the majority of the contractor community must be using it. Restrictions at this point would only undermine this effort to get programmers up in Ada. In summary, your questions suggest that the average programmer is incapable of learning Ada but somehow capable of learning say Pascal. You really show examine the motivations of you questions before you put them out for public response. ... Tony Alden TRW
emiya@AMES-VMSB.ARPA (09/12/85)
I've just read these two letters again, I think they best belong in soft-eng. They are broader scope than Ada alone. How does any contracting body tell if a contractor is worth their salt. I've seen a large number of body shops in the past six years which tells me that people bid on contracts without having the requisite expertise in house in hopes of hiring people along the way. I know this because the Xerox XTEN project tried three times hire me for what I regarded as a project which had no hope of succeeding. I don't think Ed's comments were snobbish. I think they show a real concern about how contracts are written. It's a real problem. There are too many people on the Ada bandwagon. I don't think writing Ada programs are much harder than other languages, but I do think the class of programs [real-time embedded systems] working in distributed environments are harder than your typical FORTRAN simulation or analysis package. My favorite Ada example is in Mary Shaw's book: the LaPlace solver for Cm* the 50 processor multiprocessor [done with Peter Hibbard] based on G. Baudet's PhD thesis. This six page program is otherwise, basically about 5 lines of FORTRAN on a uniprocessor [including two CONTINUEs]. It's the class of programs which are harder. Writing a spread sheet in Ada and FORTRAN is going to be about the same difficulty in either language. Many of the people who read these contracts are just managers and lawyers and procurement types. They don't know programming. They don't understand the issues of deadlock, debugging, having clear requirements..... Not all are this way, but many are. They are concern with crossing T and dotting i's [I'm being a bit extreme, sorry, flame off, too long]. EOF --eugene miya ------
nckary@ndsuvax.UUCP (Dan Kary) (09/15/85)
Tony Alden writes: > This is a very snobbish set of questions... > I call your set of questions snobbish because you are implying that Ada is > some how above other programming languages. I've read Ed Berard's article several times now and I simply do not see this implication. I do see the implication that Ada is *different* from other languages. If we were talking about spoken languages, distinguishing a translator who spoke English and French from one who spoke English and German, (but could learn French real soon) would imply a difference that is meaningful to someone searching for English to French translation without berating the English to German translator. I think this is a fair comparison, it takes time to gain fluency in a new programming language. > The major point is that if someone codes a program in Ada and the program is > sound (i.e. works well), and organized accourding to the packaging constructs > supplied by Ada then no one should have any complaints. The major point of developing and enforcing the use of Ada is to get control of the software crisis DoD is experiencing. DoD systems tend to be long lived, fifteen years is common. Of course it has to work well, more importantly it has to be maintainable. Original development is a small part of the life cycle cost of a system, maintenance is the reason the software crisis exists. A developer who is struggling to learn the language while struggling to develop the application is at a severe disadvantage to the developer who already knows the language. If I were searching for an organization to port UNIX to my new processor and had a choice between a respectable, established DP shop that specialized in COBOL applications and a startup that employed C programmers recently graduated from Berkeley (or NDSU), my choice would not indicate that I thought COBOL programmers were a lower form of life or generally less capable individuals. My choice would reflect the fact that I understand the importance of experience with the language in question. Returning to the maintainability issue, I would like to ask a fourth question. 4) From a contracting office's point-of-view: How does one specify maintainability criteria for acceptance. Obviously a program that does not work would be rejected, why should a program that is expensive to maintain be accepted? > In summary, your questions suggest that the average programmer is > incapable of learning Ada but somehow capable of learning say Pascal. Again, I see no such implication. I see (and agree with) an implication that someone who is fluent with a given language has an advantage over someone who has never used the language. I take a generic view of this list of questions. Substitute 'FORTRAN' or 'C' or whatever you want for 'Ada' in the list and it is equally valid. If a specific programming language or operating system is required for implementation of a given system (for whatever reason), then competence with that system is an important issue. I am most interested in answers to question three: > Am I improving, or getting worse? No matter what language a group is using, habits will develop. What will be the end effect of these habits? Are we digging ourselves into a deeper and deeper rut? How do we know before it's too late? > You really show examine the motivations of you questions before you put > them out for public response. Pure as the driven snow. (I see *lots* of driven snow in Fargo, ND) Dan Kary North Dakota State University Computer Science Department 300 Minard Hall Fargo, ND 58105 (701) 237-8171 ihnp4!dicomed!nckary