Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!elroy.jpl.nasa.gov!decwrl!netcomsv!jls
From: jls@netcom.COM (Jim Showalter)
Newsgroups: comp.object
Subject: Re: C++ and waitresses (long)
Keywords: C++, software reuse
Message-ID: <1991May25.051758.9731@netcom.COM>
Date: 25 May 91 05:17:58 GMT
References: <2325@media03.UUCP> <1991May24.015856.9979@csusac.csus.edu> <31061@dime.cs.umass.edu>
Organization: Netcom - Online Communication Services  UNIX System {408 241-9760 guest}
Lines: 49

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

Within reason, this is actually a promising development. Instead of
the classic "I don't have time to design it--we're already behind
schedule, so start TYPING [is THIS where the phrase "strong typing
originated? ;-)]" approach, C++ does bring with it a more
disciplined tendency to emphasize specification over implementation.
Considering that the design is really expressed via the specs, and
considering that the implementation of the average method is such
a no-brainer it could almost be automated, I think focussing on the
specs is the proper thing to do. However, see caveats below...

>So far, even after several months, precious little actual code has
>been written.  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.

This is the downside to emphasizing specification over implementation:
you can run pretty short of implemented code. This quite understandably
makes managers nervous, and in some cases it can crater a project. That
is why the projects I've been involved with that were successful also
did a lot of PROTOTYPING. Think of the spec as the theory: the prototype
is the experiment that either validates or repudiates the theory. A
methodology that emphasizes the design-a-little/code-a-little/demo-a-
little/incorporate-feedback/repeat loop tends to produce better results
than one that emphasizes design at the expense of implementation, or
implementation at the expense of design (or, as is sometimes the case,
documentation over everything...).

I would urge the people on your
project to PRETEND like they've ironed out the design, pick some critical
threads through the architecture and implement them (yes, write actual
CODE, perish the though), and then gather feedback on that prototype
to help them further refine the specs. Not only will this give everybody
a better feeling of where the project actually is, but it will help
to overcome the fear and inertia, since the stuff in the prototype
is not the "real" code (and may even be discarded), so don't get all
bound up in knots worrying about making it perfect.
-- 
**************** JIM SHOWALTER, jls@netcom.com, (408) 243-0630 ****************
*Proven solutions to software problems. Consulting and training on all aspects*
*of software development. Management/process/methodology. Architecture/design/*
*reuse. Quality/productivity. Risk reduction. EFFECTIVE OO usage. Ada/C++.    *