Re: Do you have a Knowledge Officer?



"Robert" <no@xxxxxx> wrote in message
news:0mhfg3pdinc9n3o9g8ln2lgq9h724op8ai@xxxxxxxxxx
On Sat, 6 Oct 2007 17:45:03 +1300, "Pete Dashwood"
<dashwood@xxxxxxxxxxxxxxxxxxxxxxxxx>
wrote:

"Robert" <no@xxxxxx> wrote in message
news:srmdg3l92coq5ifp54vg1ei1978fcbilu8@xxxxxxxxxx

I thought it was axiomatic, taken for granted, that everything posted
here
is the author's
opinion, unless (s) he supports it with verifiable facts and credible
logic.

I'm sure you are familiar, Robert, with the old adage that "When you
assume,
you make an "ass" of "u" and "me"...". Axiomatic means "self evidently
true", not "taken for granted", a slight but important diference.

"An axiom is a sentence or proposition that is not proved or demonstrated
and is
considered as self-evident or as an initial necessary consensus for a
theory building or
acceptation. Therefore, it is taken for granted as true, and serves as a
starting point
for deducing and inferencing other (theory dependent) truths."
http://en.wikipedia.org/wiki/Axiom

Everything posted here may well be the author's opinion, but these are
usually "informed opinions"; very few people posting here don't know what
they're talking about, even though their opinion may vary wildly from
others. That's what makes this forum valuable (and fun:-))

The phrase "don't know what they're talking about" refers to disagreements
over fact,
which can be resolved dispassionately.

Says who? A person's opinons can also be reflective of inadequate
information on the subject. It is then fair to say they don't know what
they're talking about.



It is MISused when applied to differences of
opinion.

Nope. Not in the circumstance described above.


We are back to form vs content. Some people think unminced words, spoken
directly without qualification and maybe hyperbolixed for effect, indicate
virile, no nonsense, straightforward thinking; others realize that no
matter
what the form of the message, the content is what matters. This particular
form hides woolly and illogical thinking just as well as the weasel forms
you disparage below... the content is the only measure of value, but a
bombastic, overbearing form means people don't bother to look at the
content. (That's why both agression and wheedling are useless against a
trained negotiator; he sees only the content.)

You explained that very well.

I have had negotiation training (although I don't always apply it in
everyday life...:-)) If you are ever in a hostage situation, tell them to
send for me.. :-)


The form of your posts irritates a lot of people here.

I believe they are irritated by my content. Displacement causes them to
criticize form
instead of rebutting content.

Possibly, to some extent.


I'm quite sure the
content of my posts irritates some here (although I don't post to be
irritating).

It should .. more than mine. You get away with it because you attack the
Cobol language
whereas I criticize the skill of its practitioners.

On the contrary, Robert, I don't attack anything, least of all the COBOL
language.

I have opinions about COBOL and I express them as such. I realise they are
arguable and I argue them with a spirit of fairness and goodwill.

(Having frequented this forum for many years, I know that minds rarely get
changed, but it does no harm to explore ideas with others. In the course of
doing this, understanding of individuals occurs and that is no bad thing.)

And I certainly don't get away with anything here :-)

(The point is you can't please all the people all of the time
and neither should you try to...)

What can be done about it?

It depends what you want. If you are seeking to persuade, rather than
coerce, you will modify the form of your posts. If you are posting just to
let off steam or voice an opinion, then you won't. :-)

Another option is doing something more interesting .. such as programming.

Then there would be no need to post here. I post here as relief from
programming. (that is not the only reaosn; but it is certainly a major one.


--- Quotations ---
Weasel words are almost always intended to deceive or draw attention
from
something the
speaker doesn't want emphasized, rather than being the inadvertent
result
of the speaker's
or writer's poor but honest attempt at description.

Well, the "almost always" in the first sentence is exactly what the writer
is protesting :-)

Very good observation.

I'm not going to debate the stuff you quoted because I doubt that minds
will
be changed

Then you proceed to debate it. :)

No I snipped it.

I made comments on the second part.

1. I use qualification in sentences not to deflect attention away from
what
I "don't want emphasized", or to be apologistic for my argument, or to
dilute the meaning, or because I am a ***. I do it because it is
logically
more accurate, and if you're going to debate something, you might as well
be
accurate about it.

Sure, it's more accurate, but debates don't turn on the accuracy of facts,
they're about
conclusions. It doesn't matter whether all, most, some or a good number of
Cobol
programmers are stuck in the 1970s. Defenders don't quibble about the
percentage, they're
angry about the concept of obsolescence.

Then I would suggest that people who are angry about obsolescence simply
debate that... accurately.

2. I use the passive voice (probably more than I should) for stylistic
reasons and not for dishonesty in argument.

3. There is no place in my philosophy for "weaseling". Neither in speech,
writing, thought nor action. I leave "weaseling" to Insurance Companies
and
politicians, where it seems to be alive and well.

Weasels should be offended. My pet ferrets are not sneaky or dishonest
like a politician,
they are inquisitive and adventurous like a programmer.

Like SOME programmers...:-)

<snip>>>
Only when they're task, rather than goal, oriented. Evolutionary
development
obviates this one; nothing is ever "finished", it is evolving.

You still need checkpoints to assess how far through the tunnel it is.
Without them, you
won't know until you reach the end that it's been walled off.

When code is seen to be working, it can be said to be "finished" in this
context.

The tunnel is NEVER walled off. There are ALWAYs options. Besides, it isn't
like advancing down a tunnel, more like advancing across a field.


* It must be an environment/configuration/deployment problem: this
may
be actually
true, but it usually points to a larger stability problem. If you cannot
build and deploy
reliably then why would you have confidence that the code works?

Because the deployment package has nothing to do with the application
code?
Duh!

I can sympathize with that excuse. Too often, our change control
infrastructure is
error-prone, has hidden dependencies, especially humans remembering to do
things. The
programmer gets blamed for screw-ups outside the development domain.


So, how do you handle being blamed for something that isn't your fault?

(Most of us experience this at some stage, so dealing with it is a useful
skill to acquire. Angry tirades, sulks, and standing on your dignity are not
solutions...)

Management is responsible for deployment, not developers. The problem is,
management sees
it as a techie issue, thinks 'let the techies fight it out among
themselves.' That's a
real problem.

Management are no more responsible for deployment than they are for
developing the system, but you don't see them writing code.


<snip>>>

Or it could be that it didn't get done because you were breathing down
their
necks demanding test plans, "communication meetings" and "status updates"
every five minutes, and bullying them to show what a macho Boss you are

In small companies, programmers are generalists having control over the
whole IT domain.
In large companies, their domain is limited to one application. Errors
usually occur where
domains intersect, due to communication failures. Specs say 'The other app
is already
doing that. All ya gotta do is call their service.' It's a simple concept
but the devil
is in the details.

Yes, most of us have encountered such problems. Eliminating Specs (in a
context described elsewhere in this thread) is a radical solution to it.


Again, management is responsible for keeping ducks pointed in the same
direction. Workers
are not going to do it themselves unless they're given a structure and
incentive.


It is part of the Management responsibility to provide that structure and
incentive. I am very happy to set goals , explain why we are going that way,
agree the direction and goals with the team, then let them get on with it,
providing whatever support they need. They are very capable of pointing
ducks in the right direction :-).


* I've got it done, but I need to build a few more components for you
to be able to
see it: then its not done! Encourage show and tells, code reviews, unit
tests, etc. so
that code is visible as soon as possible. Use slicing models so that you
can see pieces of
the application in weeks, not months. In addition, code that isn't
checked
in should never
be counted - that means that someone cannot build it sufficiently to
share
it. It only
counts if you can verify it. Ideally, its not "done" unless there are
sufficient unit
tests, a build script, and a document that someone walking into the code
repository could
check out the project run a build and have all the unit tests pass. Then
the code is done
- anything less is mythical.

The core processing is done.How long will the remainder take?

Programmers think their job is done when the core code is written and
working.

Do they?

It depends on the environment they are working in, and the local standards
and culture.

<snip>
* It Worked on my Machine!: programmers use this excuse to downplay a
bug. The reality
is actually the opposite - it means that you have an intermittent bug
which is by far the
worst kind of bug to have in your application. You want bugs to fail
quickly and
consistently - any variant such as "That's Weird", "That didn't happen
yesterday", "That
must be a data problem", etc. is admitting you have a bug that cannot be
easily
duplicated.

Not necessarily at all. It may well have worked on a local machine and
there
are simply configuration problems (permissions, authentication, logons,
user
profiles, dozens of factors that have nothig to do with a bug in the
application code.) with getting it networked. It isn't necessarily an
excuse for a bug, it is simply a statement of fact. You can't expect
programmers to be network administrators and configurators, if you are
employing them to write code. That's why you have separate areas of
expertise.

Exactly. But the defect is first assigned to the application team. The
burden is on them
to figure out whose fault it really is.

Who else could do that, given that Management are generally not technical?


Many of these problems are caused by fragile environments, which in turn
are caused by
Balkanization of responsibility. SOMEone should be responsible for the
health of the whole
organization.

Ah, that would be the CEO... maybe you should be talking to him/her...

If you're talking about IT then that would be the CIO and you DEFINITELY
should be talking to him/her...

Someone should fix the root cause of 'incidents' so they don't happen
again.

That is what tech teams endeavour to do.

Pete.
--
"I used to write COBOL...now I can do anything."


.