Re: Proficiency in Ada

[mshapiro@manta.nosc.mil (Michael D Shapiro)]

In article <1993Apr4.032918.783@seas.gwu.edu> mfeldman@uunet.uu.net (Michael Fe
ldman) writes:
>In article <46we2B1w165w@netlink.cts.com> mshapiro@netlink.cts.com (Michael Sh
apiro) writes:
>>
>>There's a difference between learning a language enough to use it and 
>>becoming extremely proficient in it.  An experienced programmer should be 
>>able to pick up any language similar to the one they've been using fairly 
>>quickly.  But they'll learn more and more features and techniques with 
>>use.  One of the cost models I have used (SoftCost, if I recall), assumes 
>>an Ada programmer is less than fully proficient until they've completed 
>>three projects.

>This is NOT a useful figure of merit unless it is given together with similar
>figures for other languages. Do we know how many months, years, or projects
>are required before a programmer is proficient in, say, Fortran or C,
>sufficiently to write the kind of robust and maintainable systems we all
>desire?
> 
>Without useful comparative data, you are merely perpetuating the canard
>that Ada is somehow DIFFERENT, HARDER, than its predecessors or successors.

I have no problem with that, and I make no comparisons.  I
merely reported that in one respected software costing model,
SoftCost-Ada, three Ada projects "under the belt" is taken as
the measure that a programmer will be fully productive in Ada.
The whole point of costing models is to find some easy measure
that can be extrapolated to give an indication of the actual
process.  ("X is a good model of Y if you can get a reasonable
answer on some question about Y by asking that question about
X.")

In developing their model, Reifer Consultants (213-373-8728 was
the number a couple of years ago; I think their area code
changed to 310 recently) found that a growing experience curve,
leveling off after three Ada projects appropriately predicted
productivity.  This means both that people will be less than
fully productive before they've completed three projects and
will not be more productive after they've done three.  (That's
if I remember right from my course in using the model a couple
of years ago.)

I, too, would be interested in measures for other languages.
Most software costing models I've seen count experience in years
rather than number of projects.