Re: official recommendations of Ada

[Colin_Paul_Gloster@ACM.org (Colin Paul Gloster)]

In article <5be89e2f.0107241106.5a696d65@posting.google.com>, codesavvy wrote:
">>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."

For one thing, when you followed up to Marin David Condic saying that
he must have missed that strawman post, you did not give better details as
to what post that was in (and please note this can be important if you
want to be really accountable, as I compose this there are 198 posts in
the thread already, 21 by you, I have so far read and understood 18 of
yours; but at least unlike Bob Leif you do a better job of threading).

I did read it originally. For some reason searching on
HTTP://groups.Google.com was not very useful this time
(author: codesavvy ; with word in body: strawman ; with word in
subject: Best ; from: comp.lang.ada )
but I found it again anyway. From
news:5be89e2f.0107181029.1e09f6c0@posting.google.com :
"[..] As a strawman let's define productivity as number of hours per
function point that yields less than or equal to a given defect rate per
hour of acceptance testing.  For example:

Say a developer is equally competant in Ada 95 and C++. Say this
developer uses C++ and takes 40 hours of a developers time per
function point that yield a defect rate of 1 defect per 40 hours of
testing.  Could you reasonably expect the same developer to take only
20 hours per function point that yields a defect rate of 1 defect per
40 hours of testing?  I sincerely doubt it but I could convinced
otherwise.

[..]".

As a strawman it may only have been meant as a gentle example. You may
still be ignorant of any rigorous or usefull or cheat-immune measurement
process.

"Apparently you're trying to pin me down to a metric that is useful for all
organizations which I can't do."

What I was trying was not that as such. But you have yet to name a single
one applicable anywhere which does not really indicate any familiarity
with the concept on your part. As for Russ's case: if they have some
process for current and past projects then it may be worthwhile to
continue exercising it on their new project. So far we do not know that
such a culture is already installed there.

Furthermore if you believe that there is no one way suitable for every
organization then how can you expect there to be one for a single
organisation suitable to every problem domain, apparently in the case of
Russ's organization: a problem domain they have never entered before.

"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?"

No dispute. Win me over if you want: show me that every single process
ever "that can make reliable schedules" is "accomplished by collecting
data and determining metrics for estimating future productivity."
  
"> 
 > 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."

If you would like to go on about a few that may be fine: better in a
discussion on them than mentioning exactly nought.

"My post regarding my assumption of management is self explanatory I'm sorry if
you didn't get it."

I did 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."

How exactly do you explain my drawing of attention -- at 23 Jul 2001
10:43:38 -0400 in news:slrn9lo12g.q0p.Colin_Paul_Gloster@camac.dcu.ie in 
"Re: C++ vs. Ada for safety-critical applications" on
news:comp.lang.c++.moderated -- to real contradictory systems and software
engineering practices in response to Richard's (Lao Xiao Hai's
<laoxhai@ix.netcom.com> 's) demeaning of neglecting good ideas (such as
type safety and sensible driving on roads), since Richard's comments were
detached from the conditions of these environments?

"Apparently you don't put much stock in the CMM either."

Which of course would explain why I think that something on level five of
the Capability Maturity Model would be more orderly and accountable than a
start-up at CMM1. Please have an argument, yes?

"Your analogy [was not an analogy -- the future is not determinable] 
doesn't apply to software development."

So the laws of physics are different if you adopt an on-going empirical
study of your software development process? I think not. Another
Association of C & C++ Users ( HTTP://WWW.ACCU.org/ ) member disagrees with you
on this (from the accu-general thread I already mentioned):

"[..]

Watching The Simpsons last night, Professor Frink said, when asked if the
project he was working on would be ready on time, "I have visited the
future, and yes it will."

[..]

Wonderfully appropriate to most scheduling situations in software
development. 
You can never be sure that it will be ready on time, because you can't
visit the future.

[..]"

">> 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++."

Please do not treat me as a dolt who has not read that you think that Ada
is better than C++ umpteen times. You have tried to point out to others
what exactly you have said. I will tell you exactly what "since you love
to default to C++" means. It means since you love to default to C++. Is
that clear? Many times you have shown us that you would choose C++ over
Ada on a non-technical justification if you were not shown that Ada would
be much more productive than C++ (not a symmetric condition though, you
would use C++ without being shown that it is much more productive than
Ada). 

Saying
"Excellent, you're probably going to have an incredibly hard sell"
is a point of evidence for this.
  
"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."

You are not adding anything new to the discussion here. Indeed you quoted
my quoting of you saying that.

"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."

There is not even one definition there already. So what if I decide I am
going to coin "rational management" to be an adjective meaning hairier
than yellow? What benefit would there be in striving to ensure that
whatever you are aiming for fits every possible meaning denoted by a label
(a lazy shorthand which can be confused with identical labels denoting
subtly and unsubtly different concepts) of "rational management"?
  
">> (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
[..]"