Re: Notes from the Real World

From: jmjonesat_private
Date: Tue May 01 2001 - 17:03:48 PDT

  • Next message: Greg KH: "Re: Notes from the Real World"

    On Tue, 1 May 2001, Greg KH wrote:
    > On Tue, May 01, 2001 at 07:13:15PM -0400, jmjonesat_private wrote:
    > > Works well for coders, not software designers.  In many shops (my own 
    > > included) the coders are writing to SPEC... the SPEC being human language.
    > > The translation from code to human to code often results in new and better
    > > results.
    > Ah, but who wrote the implementation spec in the first place?
    In my shop, the software designer, who will test the code, not write it.
    > My odds are on the the people who are going to be doing the coding. What
    > I am trying to say here, is that if the coders themselves do not create
    > the specs, the two trees rapidly diverge, with a lot of effort to keep
    > them together.  
    I know what you're going to say "apple pie and mom"... but the fact is, 
    the documentation follows the code, which responds to the documentation, 
    which follows the code.  There need not be a "great" divergence, if the 
    effort is truely cooperative.
    > I've worked in ISO-9000 shops, so I understand well the spec
    > and paper trails needed.
    Ouch, poor you.  I'm not suggesting THAT.  What I'm suggesting is
    following your efforts with HUMAN LANGUAGE descriptions, and feeding 
    the insightful comments back to you.  
    > And if the people doing the coding are not the same people who
    > wrote the implementation specs, I feel sorry for them, and you should
    > tell them that there are much better jobs for programmers out there.
    Um, possibly, but that, in my world, is the job of the "Systems Analyst",
    and I think every programmer should strive to perfect his/her art to the 
    point where he/she can move up to System Analyst or System Administrator.
    > > I do not intend to imply THIS information is not necessary.  It is.  But 
    > > I think an outside evaluation of this project in HUMAN-READABLE terms may 
    > > help develop a more "rounded" implementation.  I intend to undertake it,
    > > and don't see it as wasted time, unless you and yours' will ignore the 
    > > results?
    > Ok, more power to you.  I will not ignore the results at all.  I just
    > wanted to make sure that you understand the difficulty of it.  And since
    > you do, I welcome reading the document.
    I do understand the difficulties, but *I* see it as a worthwhile venture, 
    as long as the coder side will AT LEAST review and REJECT the
    documentation side's thoughts.
    > > Are you afraid of critical review?
    > Not at all, I welcome it.  It's the only way people grow.  I wouldn't be
    > writing open source code if I didn't like criticism :)
    I knew that, but was trying to make a point.
    > > After all, isn't the POINT of a loadable module interface to move stuff
    > > OUTSIDE the kernel in a coherent way?
    > No, a kernel module interface is there to provide a clean interface to a
    > subsystem.  It allows pluggable systems.  Think of loadable device
    > drivers. It does _not_ move anything outside of the kernel.  Remember
    > module code still runs within kernel space, with all the privilidges and
    > pitfalls that are there.
    Okay, I stand corrected, but a loadable module DOES provide a means of
    extending the kernel to provide other functionality without actually 
    touching the Kernel proper.  Not So?
    > > If I (and others) can write a document that helps make this interface more
    > > understandable... why do you object?
    > I'm not objecting at all.  I just was trying to propose what I see as a
    > simpler method to create the documentation, that's all.
    I agree with your perspective, but also think it's "monocular".  Another 
    perspective, MAYBE, could help.  I *applaude* the desire to document code 
    WITHIN code... it makes maintenance programers' job SO much easier (if not 
    POSSIBLE, in the first place), but my thoughts are to the Software
    Designers OUTSIDE the coding spectrum who need to be informed of what 
    the interface provides, so they can spec projects that make us all 
    > Looking forward to the documentation,
    Looking forward to the code.
    > greg k-h
    J. Melvin Jones
    ||  J. MELVIN JONES            jmjonesat_private 
    ||  Microcomputer Systems Consultant  
    ||  Software Developer
    ||  Web Site Design, Hosting, and Administration
    ||  Network and Systems Administration
    linux-security-module mailing list

    This archive was generated by hypermail 2b30 : Tue May 01 2001 - 17:19:19 PDT