Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 3 May 1997 08:41:54 -0700 (MST)
From:      Terry Lambert <terry@lambert.org>
To:        hasty@rah.star-gate.com (Amancio Hasty)
Cc:        terry@lambert.org, donegan@quick.net, jhay@zibbi.mikom.csir.co.za, jdp@polstra.com, current@FreeBSD.ORG
Subject:   Re: -current build is now broken..
Message-ID:  <199705031541.IAA12499@phaeton.artisoft.com>
In-Reply-To: <199705030249.TAA15482@rah.star-gate.com> from "Amancio Hasty" at May 2, 97 07:49:33 pm

next in thread | previous in thread | raw e-mail | index | archive | help
> You failed  to take into consideration the culture and level expertise
> involved. Yes, it is generally true that is good to have problems pointed
> out however :
> 
> 1. Some environs quickly forget to tackle problems and chose the easy
>    route of pointing out problems.

Honestly, the only place I've ever seen this is where the problems
were out of the zone of control of the person complaining, either
because it's out of the person's authority, or the zone of control
is artificially restricted.  I suppose that you could have habitual
whiners... if so, the strategy he suggests would be one of the two
most effective ways of dealing with the problem ...the other being
"fire the guy", which is probably less effective, since it sets a
bad precedent "complain and you'll be fired".  Of course, "complain
about upper managements crisis management and we'll invite you to
the crisis" is also a bad precedent, but at least you won't lose
your workaholics over it.


> 2. If you are aware that the individual can help and is lazy by way of 
>    just pointing the problem specially when you are up to your ears
>    with the situation then why not help ?

You mean "why not ask him to help"?  If so, I agree.  That's the
"habitual whiner" case, above.  I think it is relatively rare.


> 3. Is always easier to point out problems than to contribute. 

If this were true, software companies would not explicitly hire
test engineers.  8-).

Actually, I have been involved in a number of organizations with
significant barriers to contribution.  USL, for instance, maintained
their source tree in such a way that you have to pull pieces from
three different trees out of a larger set of trees in order to get
a buildable SVR4 source tree.  Then they centralized the "keys to
the source tree" in a few individuals, just to make sure you got
the point that any change by someone without keys was not only not
appreciated, but intentionally discouraged.  If you wanted to make
a change that affected anything central enough to be platform
dependent in implementation, well, you just decided on a two year
career goal for yourself.  At USL, it was *always*, *unconditionally*
easier to point out problems than to contribute.  Mostly because
the problems they had were comfortable, and contribution was not
just difficult, it required potentially career-limiting risks to
get anywhere.

It's generally not difficulty, but danger, that weighs against
contribution.


> Some companies bypass this level of cultural management and they
> just simply swamp their brilliant minds with work in the hope of
> keeping them focus in the process.

Ah... "focus"... the 1990's substitute for "vision".  "Forget vision,
if only we had enough focus, we could get that stock price up...".
Companies which do this rarely achive their hopes.

| We've all heared that a million monkeys banging on a million typewriters 
| will eventually reproduce the entire works of Shakespeare.  Now, thanks 
| to the internet, we know this is not true.
|		-- Richard Jenkins <rich2@dial.pipex.com>

(Seemed appropriate for a "process is the product" discussion).


> As for bug reporting , if I think that the bug reporter can actually
> fix the bug -- I feel morally obligated to ask for a patch well at least
> thats my attitude when it comes to public domain work.

Maybe it was just my inherent bias here.  I generally don't complain
unless there's no way for me to make the change myself.  Typically,
this boils down to management vs. technology (and in my book, until
the Catholic Church builds light bulbs that work from only the data
available from doctrine, technology should win that battle).


					Regards,
					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199705031541.IAA12499>