Re: PROPOSAL: UISG Menu Line Standardization



Think about this message before you respond, Bowie... don't respond
instantly.

On Sun, 9 Aug 1998, Bowie Poag wrote:
> Well, you'de think over the course of spending the past 6 years nearly
> continuously, working with programmers from several different countries,
> on several different projects, you TEND to see the common threads among
> all of them, JR. There is *definately* a "programmer mentallity". The
> personality of most prorgrammers will vary widely depending upon their
> individual skills and disciplines, but they ALL share common threads;
> Among them, the lack of interest in writing formal text documentation for
> their programs. This is often their LAST concern, when developing.

Exactly.

And I say that when Bowie says, "I wash my hands of this: people don't
like to do it" is not only irresponsable but also flat out ignorant.
 
> sorry, I just really fail to see what youre getting at here, but i'll
> answer your question anyway.

I'll say it straight so you won't get confused again: the user should have
a well documented application at their fingertips whether or not the
programmer likes to write documentation.

> Since 1992, most of the coders i've worked with have been developing
> things with an emphasis on graphics programming. Formal projects, not

And graphics programmers (of which I am one, heavily) are known for being
the most insane, careless of the lot.

> that, I can go back to 1988. The average age of the programmers I've
> dealth with, falls usually between the ages of 22-26, almost without
> exception. The youngest coder I've worked with on a project

Six years?  Are you trying to say that dealing with 25 year old
programmers for six years makes you an industry veteran that knows what
programmers will and will not do?  I'm sorry, it simply doesn't work that
way.

Go pick yourself up a copy of The Mythical Man-Month, Bowie... you're in
dire need of it.  If you've read it before (which I would presume that you
have, considering that it is almost required reading for any serious
software developer / team leader), then perhaps you need to read it again.

People who study these kinds of things for years have already given us the
answers: they dedicated their lives to writing books about it.  Fred
Brooks (author of TMMM) is just one of those people.  Read it.  Don't
rediscover the mistakes that everyone else has already discovered (re:
bowing down to what you think "the programmer" wants).
 
Do you even know the difference between an essential and accidental
difficulty?  Documentation is neither!  It's not difficult!  Boring,
maybe, but not difficult!

> A) Professional programmers dont write documentation. Uusally, most

Okay, Bowie, I finally believe that you have no firm grounding in reality.
Professional programmers write documentation day in and day out.  No, they
don't write the documentation to the interface because other people are
employed to do that already... but they do write documentation.  If they
didn't, the software world would be twice as screwed up as it is already.

> professional firms have specific people FOR that task, who are
> familliarized with the project after it has already entered beta. How do
> -I- know? Because I -am- one of those people. 

You write documentation?  Good!  Then you should see my point:
documentation is so critical that people need to do it.
 
> > Does this make it right?  When the heck was the last time a man page
> > helped any normal, average user out?
> 
> Hehehehe..god, this question is so clueless that I'm not even going to
> bother adressing it. 

Clueless?  I'm beginning to wonder who has all of the clues here, Bowie.

I'm asking you straight out (and you haven't answered): If the programmer
doesn't want to do it, does that make it right that he doesn't?  

Why don't you write a style guide called Programmers Lives Made Easy?  Or
at least subtitle the one you're working on w/that line...
 
> > I would also propose that there are coders out there who feel it
> > sufficient that their application only crashes 75% of the time.  Does that
> > make it right?
> 
> Depends. Its fine for an alpha, or even a beta. But for most peoples
> standards, its unacceptable for what most people refer to as a "stable"
> release version.

Right.  But programmers don't really have the most fun debugging: the real
fun is in writing the code... yet releasing a buggy application is
unacceptable... therefore, there is no direct tie between what programmers
like and what is acceptable in the final product.  Do you understand?
 
> > > for their program to gain more acceptance in the public.  You cant force
> > > them, ala a Style Guide requirement, to write dox -- They'll reject it
> > > outright.
> > You're wrong on this one, Bowie.  You *can* force the programmer to write
> > documentation.  It happens all day and all night in this industry: look at
> > any software review in any magazine of a product that had shoddy
> > documentation and you will see that lack of documentation is spit at. 
> A) This isnt an industry. Nobody is getting paid.

What are you aiming at here, then?  I guess I'm missing the point of this
whole thing.

I thought the point of free software was to do for free what everyone else
was doing for money, but better.  Apparently, in your eyes, free software
is about screwing around and just doing what's fun... 

> B) Force a programmer to do something against their better judgement, JR..
>    Then watch them laugh in your face.

I am a programmer, and I lead a project.  I tell my teammates to do things
against their better judgement.  They don't laugh in my face.  Why?
Probably because I've educated myself on these decisions and talk about
them more than you seem to (re: TMMM, Thick Face Black Heart, etc).
Probably because they respect me and my work enough to know that I
wouldn't lead them down the wrong road.  Probably because I care about the
product as much as they do, and not what makes their lives easy.

People need leaders to make the decisions that they don't want to make.
Good leaders don't appease their people all day... that's what we call a
wimp.

> C) Rules for commercial software do not apply to what we're doing. Might
>    wanna swing by www.gnu.org when you've got a minute.

Rules for software do.  "Free software" does not mean "do whatever the
hell you please: it'll all work out in the end."  Might wanna look into
Real Life when you've got a minute.

Are we forgetting about World Domination 101?  (Do you even catch the
reference here?)  

> > And I'll bet my rear that it's the right thing to do (requiring
> > documentation).
> Hope you've got a spare. :)

Haven't lost mine yet.

Now I see why Microsoft has been walking all over the Unix market for the
past few years: they have vision, clarity, and goals and are willing and
ready to do whatever it takes to reach those goals, that ultimate vision.  
Whether or not it is right is less relevant than the fact that they are
willing to make the decisions that people like you do not want to make.

william r. tipton



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]