From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,be9bf965710b207c X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-07-24 01:00:38 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!newsfeeds.belnet.be!news.belnet.be!uni-erlangen.de!news-nue1.dfn.de!news-han1.dfn.de!news-koe1.dfn.de!do.de.uu.net!newsfeed.esat.net!news.heanet.ie!Colin_Paul_Gloster From: Colin_Paul_Gloster@ACM.org (Colin Paul Gloster) Newsgroups: comp.lang.ada Subject: Re: official recommendations of Ada Date: 24 Jul 2001 08:13:27 GMT Organization: student member (not a representative) of the ACCU; SIGAda; and Ada-Deutschland (earliest first; latest last) Message-ID: References: <5be89e2f.0107200443.678562ea@posting.google.com> <5be89e2f.0107210501.4d268a00@posting.google.com> Reply-To: Colin_Paul_Gloster@ACM.org NNTP-Posting-Host: ns.dcu.ie X-Trace: kenraki.heanet.ie 995962407 5973 136.206.1.3 (24 Jul 2001 08:13:27 GMT) X-Complaints-To: news@kenraki.heanet.ie NNTP-Posting-Date: 24 Jul 2001 08:13:27 GMT User-Agent: slrn/0.9.7.0 (SunOS) Cache-Post-Path: ns.dcu.ie!unknown@camac.dcu.ie X-Cache: nntpcache 2.3.3 (see http://www.nntpcache.org/) Xref: archiver1.google.com comp.lang.ada:10496 Date: 2001-07-24T08:13:27+00:00 List-Id: In article <5be89e2f.0107210501.4d268a00@posting.google.com>, codesavvy wrote: "Pascal Obry wrote in message news:... > codesavvy@aol.com (codesavvy) writes: > [..] > > What is the major risk ? > [..] There's also a risk in not finishing the project. > You probably know the statistics: more than 80% of projects (at least in my > domain which is Information System) are doubling the budget or the time to > deliver or both. > 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. Perhaps eventually in "Ada The Best Language?" someone pointed you towards a metric other than Source Lines Of Code but it seems that you are still as ignorant of empirical productivity metrics now as you were when you started that thread. 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.. "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. 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 (Russ) wrote in message news:... > 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.