NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/software/5119

Text File | 1992-12-22 | 5.1 KB | 117 lines

Newsgroups: comp.software-eng
Path: sparky!uunet!spool.mu.edu!darwin.sura.net!paladin.american.edu!howland.reston.ans.net!zaphod.mps.ohio-state.edu!menudo.uh.edu!sugar!claird
From: [e-mail] (Cameron Laird)
Subject: Re: When do we inspect [getting LONG]
Organization: NeoSoft Communications Services -- [phone]
Date: Tue, 22 Dec 1992 14:59:07 GMT
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Lines: 106

In article <[e-mail]> [e-mail] (Mark Shanks) writes:
>In article <[e-mail]> [e-mail] writes:
>
>>In article [e-mail],
>>[e-mail] (Cameron Laird) writes:
>>cl> I assert:  source code should go into the CM system
>>cl> from its first day.  ...  Some object
>>cl> that checking in source is too much overhead; for
>>cl> me, that's only a symptom that the check-in process
>>cl> isn't yet adequate.  Coders should *want* the benefits
            .
            .
            .
>>Au contraire.  Since we are not yet, and may never be, at a
>>point where we all think alike and work alike, I suggest that
>>each programmer should be allowed to do his or her own work
>>in whatever manner allows them to be most productive.  If
            .
            .
>>I suggest that a unit of code should enter a "Software
>>Development Library" at the time when the individual team
>>member has finished coding and unit testing it
>
>>I further suggest that there should be a "Project Software
>>Library" controlled and managed by a Software Quality
>>Assurance group/team/organization, and that Unit A must be
>>entered in the PSL prior to being released for use by Team
>>B.
>
>I believe Cameron misunderstood me, or perhaps has a different
>working model for "CM" than I do. I was referring to a simple
>"vault" type of tool; no regression testing, no semantic analyses,
>no nothing but a freeze on the code and enforced procedures to
>check it out and make changes.
>
>I guess Jeff's description of a "SW Development Library" is
>less restrictive than a typical CM system. I can understand
>a customer's desire for tracking changes, but IMHO, taking a
>"snapshot" at CDR time accomplishes that function without
>incurring the truly prodigious overhead entailed by some
>CM systems (check out package, make changes, inspect, fill
>out software change request (SCR) form, meet with configuration
>control board, edit SCR, check package back in, get change from
>customer, goto line 1). I'm on a program using Ada, heading a
>team of 10 software designers producing well over 200 Ada
>packages and close to 20,000 LOC. Multiply that by 30 or 40
>such teams and see how much time will be spent on CM alone.
>Why start that process any sooner than necessary?
            .
            .
            .
This has been interesting.

Some of this must be that we have different models
of CM.  I've received a number of replies, and they're
ALL over the map.  It's not even violent agreement vs.
violent disagreement, but people simply have much,
much different ideas about CM.  This has been good for
me, personally, to learn about the range of CM prac-
tices in our industry.

I'm not sure what our next step is.  The model you
describe sounds to me like a nightmare; on the other
hand, some of the people who agree with you that CM
can wait until near the end are friends of mine, and
some are objectively more successful than I, so I
see no easy resolutions.  I'll try to make two points
in closing:
1.  in discussions of CM, someone often echoes Mr.
    Hull's observation that

    Since we are not yet, and may never be,
    at a point where we all think alike and
    work alike, I suggest that each programmer
    should be allowed to do his or her own work
    in whatever manner allows them to be most
    productive.

    I suspect that our different models of CM must
    hinge on this theme, because I see our personal
    styles as acting in completely orthogonal
    dimensions to those CM constrains, but this ap-
    pears to be a big issue for others.  Is there
    someone who can explain this so that both sides
    can understand what's going on?
2.  The inflexible system Mr. Shanks describes is,
    I know, favored by some knowledgeable and exper-
    ienced engineers.  Mr. Shanks, are you saying
    that you approve of the way it is, or that you're
    stuck with something you see as suboptimal, and
    therefore you don't wish to "start that process
    any sooner than necessary"?  If the former,
    please fill in a few more of the details on how
    such a system is a benefit.  It would make me
    feel as though I'm in a trailer factory, say,
    welding away on my assigned joints, and I notice
    that I need more light on my worktable to jig up
    the pieces carefully.  I get the feeling that,
    in the factory where you work, I'd have to call
    a meeting of the union first.  Is there no
    cheaper way for me to improve my process?
--

Cameron Laird
[e-mail] ([e-mail])    [phone]
[e-mail] ([e-mail])      [phone]