From: Bob Stout 

On Fri, 30 Apr 2004, Bruce D. Wedding wrote:

> Those XP threads are so big,

I wasn't aware until I posted it that my last post was 22k. 

> Bob and Jon claim that "blame" is necessary for learning,
"cutting a
> weak member loose" and as a feedback mechanism.  I can't argue that is
> is not valuable to know when you make a mistake.  It is obviously
> valuable, to some degree.  What I've seen now that I've been doing this
> for a while is that we ALL make mistakes.  I do not learn from the type
> of mistakes I make now. They are intrinsic to what we do, every industry
> has their analogous mistakes.  Draftsmen draw something mirrored and the
> bolt holes don't line up.  A physician misses tying off one vessel or
> leaves a scalpel in there when he closes.

No argument from me. This gets back to my point that who introduced the
error is often less important than how it was introduced. Knowing how can
often spotlight design deficiencies. As you say, stuff (or one of those
"s" words) happens. The real question is whether the design or
even the coding standards can be revised to make it less likely to happen
again?

OTOH, it's still a useful feedback mechanism. If I know that 7 of my last
10 bugs related to some common error, I can be more aware of it in the
future.

Just today I was bitten by my reliance on compilers that issue errors when
a function fails to return a value of the type specified. The Microtec
compiler we use for the 68332 only issues a warning which can be easy to
overlook when doing a rebuild, so I'd added a simple (basically one line)
function but failed to have it return what it should. Since its purpose was
to write something to the system error log and since a non-zero return
value caused the triggering event to be requeued for later execution, the
function wound up being called each time through the top-level state
machine loop, or about every 20 mSec. When the event log overflowed memory,
the system crashed.

As you say, we're only human, but sometimes it's handy to know the
weaknesses of both yourself and your tools.

> Obligatory anecdotal story:  My boss and I split 59 software changes
> to make a new release of software.  We divided them based on estimated
> effort so it wasn't 29-30 necessarily.  In any event, I completed my
> changes on time and my boss was way behind.  What did she do?  She sent
> emails to me, the director and the VP claiming that one of my changes
> didn't work right. I knew immediately that she was deflecting blame.
> Don't play that game with me if your ducks aren't in a row because I
> will shove it down your throat. I replied back asking exactly WHAT was
> broken and asking her to clarify that ALL of her changes were complete
> and I was holding up the release.  She mentioned something in my code.
> It was subjective, not a bug, a matter of opinion.  I agreed with her
> changed the code in one day and emailed all, "Let's release this baby,
> I'm ready now."  Guess what?  She was caught like a deer in the
> headlights.  I ultimately inventoried her code and found that she
> hadn't started on 10 of the changes and I found bugs in 7 of the
> changes she did make.  You can bet your ass that the VP on down knew all
> about it.

The issues I see with this:

1.  As an experienced manager, I *never* loaded myself into the critical
    path of any active project. If I contributed anything, it was always
    ancillary tasks, such as writing protocol emulators - necessary things
    out of the critical path which I could offload from my people to help
    them remain focused on more important stuff. Over the years, I have to
    say that every "working manager" I've witnessed did a poor job of
    either the "working" or the "manager" part.

2.  Your boss shouldn't play politics - she isn't very good at it. Never
    lay a paper trail that can be turned on you.

3.  Your boss is also not a very good manager. Part of her job it to make
    your job as productive as possible. Engaging in a public confrontation
    with one of her direct reports is bad for everyone.

4.  Your reaction was also overkill. Deliberately pointing out your boss'
    shortcomings isn't wise for any employee. I understand why you did it,
    but you could have handled it more diplomatically. You can be assured
    that you're now in the cross hairs of the person responsible for your
    paychecks.

> To clarify my position; yes, learning can occur from some mistakes.  I
> assert that blame and accountability are not necessary ingredients to
> the equation though.  I make a distinction between identifying the
> problem and blaming someone for the problem.  It doesn't mean that we
> all don't know who broke the code.  The one that did will know it, I
> assure you.  But it serves no purpose to name him in the Monday status
> meeting other than, as Jon pointed out, empire building.

I originally said accountability. Jon's the one who introduced the word
"blame" into the discussion. I think my choice of words was
better because it avoids the pejorative connotation associated with blame.
Human errors may or may not incur blame, but those who make them should be
held accountable for them.

-------------------------------------------------------------
Consulting: http://www.MicroFirm.biz/ Web graphics development:
http://Image-Magicians.com/ Software archives:
http://snippets.snippets.org/
  c.snippets.org/   cpp.snippets.org/      java.snippets.org/
  d.snippets.org/   python.snippets.org/   perl.snippets.org/
  dos.snippets.org/ embedded.snippets.org/ apps.snippets.org/
Audio and loudspeaker design:
  http://LDSG.snippets.org/   http://www.diyspeakers.net/

--- BBBS/LiI v4.01 Flag-5