Newsgroups: comp.object
Path: utzoo!utgpu!news-server.csri.toronto.edu!torsqnt!geac!alias!rsargent
From: rsargent@alias.com (Richard Sargent)
Subject: Re: C++ and waitresses (long)
Message-ID: <1991May27.143914.10592@alias.com>
Keywords: C++, software reuse
Sender: news@alias.com (0000-news(0000))
Organization: Alias Research Inc., Toronto ON Canada
References: <2325@media03.UUCP> <1991May24.015856.9979@csusac.csus.edu> <31061@dime.cs.umass.edu>
Date: Mon, 27 May 1991 14:39:14 GMT

In article <31061@dime.cs.umass.edu> connolly@livy.cs.umass.edu (Christopher Connolly) writes:
>My experience so far suggests that a more accurate statement might be
>"Many will successfully produce `.H' files.".  Certainly, there will
>be successful products implemented in C++, but in a major industrial
>site that I work at, there is an alarming trend: People who have been
>charged with writing C++ code have, by and large, been producing
>specs, class declarations and function prototypes in #include files.
>So far, even after several months, precious little actual code has
>been written.  

This is funny! If you look at the world of Information Systems
(where I actually started many years ago), this is exactly what
they DO want to achieve. The claim there is that people start
coding TOO SOON, before they understand the problem fully.

The studies done by various groups (I can't recall exact attributions)
seem to all agree that you want to push as much "correctness"
into the earliest stages of the development cycle, since fixing
things during testing "costs" about 1000x (!) what it would have
cost to found the problem earlier in the design cycle. Personally,
I find the number 1000 to be too large to want to take on faith,
but that is what I have read. Probably, it is true for a major
system for a major company, such as American Express, or perhaps
Exxon, etc. Most projects I have ever been involved leave me
claiming the cost factor is closer to 100x than 1000x, but it
is still a huge factor.

>               The problem appears to be not knowing where to start
>and how to implement.  I think Kriens' points apply directly to this
>situation.  They are faced with too many choices and are afraid to
>commit themselves.  I am fairly convinced that this would not have
>happened if the project's language had been C.
>

I am sure that this wouldn't be the case if they were using C.
I fear that they would have been implementing from day 1, and
then spend many extra months "debugging", including revising
some significant design decisions.


I have done it both ways. I much prefer getting it right, up front.
Check out some of the Software Engineering studies/discussions.
