"Geeks" and licensing

From: Richard Erlacher <edick_at_idcomm.com>
Date: Sat Dec 15 21:13:35 2001

Well, perhaps the reason for all the meetings and other work you find
uninteresting is that it's necessary to arrive at a firm specification for what
you have to build before you go off and build it. Since the coding, compiling,
and debugging only represent about 5% of the task, the bulk of the work has to
happen sometime, and that's what the "other" stuff is.

Dick

----- Original Message -----
From: "Dave McGuire" <mcguire_at_neurotica.com>
To: <classiccmp_at_classiccmp.org>
Sent: Saturday, December 15, 2001 12:25 PM
Subject: Re: "Geeks" and licensing


> On December 15, Jim Davis wrote:
> > IMHO: All software development should be performed as such:
> >
> > 1) Requirements - what should it do, and not do. Spin this till
> > everybody
> > signs off.
> > 2) Prelim design - Ok, a rough outline of the design, data structures
> > and control/data flow defined here.
> > 3) Detailed design - Define all the modules and their function, break it
> > down.
> > 4) Test plan - integrate testing into detailed design, make it unit
> > testable.
> > a unit is somthing that has input and output and side effects, like a
> > function.
> > 5) Finally, coding - build modules in parallel with test code.
> > 6) Unit testing - verify that modules comply with detailed design.
> > 7) Integration testing - hook it all together, make sure it works, apply
> > test plan developed in step 4 for fully integrated aplication.
> >
> > Do 1-3 until marketing decides what they want,4-7 until you find no
> > errors.
> >
> > For safety critical, you should /have to perform statement and decision
> > coverage in
> > step 6 and 7 and the detailed design should have a one-to-one
> > corespondence
> > with the detailed design document.
>
> Hmm, that procedure "reads" nice, but it sounds like more meetings
> than actual work. But then I've been a software developer for about
> twelve years, and nobody that I've worked with can figure out how I
> can blow off all the meetings and not get fired...it's because I end
> up writing all the code that the rest of the developers are talking
> about in their meetings, WHILE they're in their meetings, and by the
> time they're doing screwing around, the code is running.
>
> Procedures are nice, but they can be taken too far. Goal-orientation
> is better.
>
> (While I'll freely admit that this approach simply doesn't work for
> multi-million line applications, I should state that I generally work
> on applications of less than one million lines, but generally more
> than 100,000. I further state that my methods should probably NOT be
> used in life-critical applications...more than two eyes need to look
> at that stuff, no matter what.)
>
> -Dave
>
> --
> Dave McGuire
> St. Petersburg, FL "Less talk. More synthohol." --Lt. Worf
>
>
Received on Sat Dec 15 2001 - 21:13:35 GMT