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-25 01:05:24 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!news.tele.dk!212.74.64.35!colt.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: 25 Jul 2001 08:23:26 GMT Organization: Dublin City University Message-ID: References: <5be89e2f.0107200443.678562ea@posting.google.com> <5be89e2f.0107210501.4d268a00@posting.google.com> <5be89e2f.0107241106.5a696d65@posting.google.com> Reply-To: Colin_Paul_Gloster@ACM.org NNTP-Posting-Host: ns.dcu.ie X-Trace: kenraki.heanet.ie 996049406 8172 136.206.1.3 (25 Jul 2001 08:23:26 GMT) X-Complaints-To: news@kenraki.heanet.ie NNTP-Posting-Date: 25 Jul 2001 08:23:26 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:10549 Date: 2001-07-25T08:23:26+00:00 List-Id: 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 '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:... > > 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 [..]"