Re: official recommendations of Ada

[codesavvy@aol.com (codesavvy)]

>>In a subsequent portion of the thread I made a reference to a
  productivity metric.  I stated that if they are not taking data and
  applying a metric then I'd start by getting them to do that.  That
is
  the only way that I know of to start making accurate estimates."

Hold on. You did not refer to a productivity metric. You imagined that
there is a productivity metric. In
news:5be89e2f.0107221953.8a52@posting.google.com you actually said
"[..] I was assuming that management could accurately predict the
level of
effort needed to complete projects and had meaningful productivity
metrics in place. [..]". I have not read all of your posts in your
"Ada
The Best Language?" thread but I have not seen you actually describe
properly nor name any of these metrics which you claim would be
useful.<<

First of all I did look for the productivity metric that I posted as a
strawman and I couldn't find it in that thread.  Apparently you're
trying to pin me down to a metric that is useful for all organizations
which I can't do.  The point is that the current thinking in software
engineering is that processes that can make reliable schedules are
accomplished by collecting data and determining metrics for estimating
future productivity.  Do you dispute this?


> 
> Also, instead of saying that subsequently somewhere in this thread you
> said something, please have the decency to make a better reference as to
> how exactly your post can be found. Right now for me it was not a problem,
> but imagine you make another five posts with fairly similar claims and
> someone else only then starts reading the thread. Without scruntizing
> timestamps (and not all archives show the timestamps nor show a diagram of
> which post is in which subthread) it may be difficult for them to see if
> you are backtracking etc..
> 

Ok but I don't want to get hung up on a specific metric which you seem
to want to discuss.  My post regarding my assumption of management is
self explanatory I'm sorry if you didn't get it.


> "So if the organization has accumulated data from previous development
> projects the schedules should be accurate."
> 
> Where Russ is does not seem to have ever worked on a safety critical
> mission before so why -- how even -- would it have its own records on
> previous schedule programmes? As for histories ensuring future timeliness,
> bear in mind that one of the founders of financial applied maths -- a
> French man named Bouchalleit (unsure of spelling) -- maintained that the
> past and present have pretty much no bearing on future prices.<<

Apparently you don't agree with the current thinking regarding
software engineering processes.  Apparently you don't put much stock
in the CMM either.  Your analogy doesn't apply to software
development.

>> And since
> you love to default to C++ (e.g. evidence from
> news:bebbba07.0107162313.66a58a69@posting.google.com with added stress:
> "18k11tm001@sneakemail.com<<

Huh?  What does this mean?  I've already acknowledge that I think Ada
95 is a better programming language than C++.

I'll try to make this clear.  My original response in this thread was
based on an assumption of what I consider to be rational management. 
I don't think that I'm the only one who shares those opinions.  If
management is acting irrationally I would start by trying to get them
to act rationally.  This is the same approach that is taken in other
disciplines when analyzing and discussing the decision making process.
 If you have another definition of rational management then please
bring it to the forefront.

>> (Russ) wrote in message
> news:<bebbba07.0107162313.66a58a69@posting.google.com>...
> > I work in an environment dominated by C/C++, and I would like to
> > recommend Ada for a safety-critical application that is about to be
> > initiated. 
> 
> EXCELLENT, you're probably going to have an incredibly hard sell [..]" )
> when productivity studies extolling Ada are not winning you over, perhaps
> you would like to look at the "accu-general: Making estimates about
> work" thread from this month on the accu-general emailing list of the
> Association of C & C++ Users ( HTTP://WWW.ACCU.org/ ; archive available to
> members only; I highly recommend membership of the ACCU).
> 
> From the first of these accu-general posts:
> "[..]
> 
> How do you all approach the task of making estimates of how long it will
> take you to do your work?
> 
> [..]".
> 
> A not necessarily representative but not the only response of this sort:
> "When I'm spending time & effort on having realistic estimates, I try to keep
> track of how long previous tasks took. Then I base estimates on past
> performance. i'm still not very good with estimates, though."
> 
> Back to "codesavvy":
> "If the organization does not believe in taking such data then I don't know
> that they will ever realize that Ada helped them if they use it.
> 
> [..]"
> 
> But if they just start collecting these data (which you have yet to
> satisfactorily (or even try to) exhibit that they work and that you
> understand anything about collecting them and exactly which sorts of data
> these are anyway) from right now as opposed to having already had a
> tradition of doing so, they will not have enough of a sample space for
> many years. This is not to denigrate harvesting, but you did not get Russ
> to back you up on such a practice already being installed therein so you
> have a problem there.