Re: Do you have a Knowledge Officer?

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. It is MISused when applied to differences of
opinion.

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.

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.

"Displacement is a subconscious defense mechanism whereby the mind redirects affects from
an object felt to be dangerous or unacceptable to an object felt to be safe or acceptable.
For instance, some people punch cushions when angry at friends; a college student may snap
at his or her roommate when upset about an exam grade.

Displacement operates the mind subconsciously and involves emotions, ideas, or wishes
being transferred from their original object to a more acceptable substitute. It is most
often used to allay anxiety."
http://en.wikipedia.org/wiki/Displacement_%28psychology%29

Eric Hoffer explained displacement this way:

"There is perhaps no surer way of infecting ourselves with virulent
hatred toward a person than by doing him a grave injustice. That others
have a just grievance against us is a more potent reason for hating
them than that we have a just grievance against them. We do not make
people humble and meek when we show them their guilt and cause them to
be ashamed of themselves. We are more likely to stir their arrogance
and rouse in them a reckless aggressiveness. Self-righteousness is a
loud din raised to drown the voice of guilt within us. There is a
guilty conscience behind every brazen word and act and behind every
manifestation of self-righteousness."

- Eric Hoffer, The True Believer

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.

(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.

--- 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. :)

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.

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.

http://www.slate.com/id/2126636/

Developer Weasel Words
Thursday, June 21, 2007

As a development manager or project manager, you here a lot of weasel
words and excuses
from your staff or from external consultants who are trying to hose you
into believing
things are better than they are. In many cases, developers use these
phrases to even
convince themselves that things are better than they are, resulting in
chronic late
delivery and poor quality.


As you have never experienced late delivery, I'm surprised you took note of
this :-)

I'll buy the part about poor quality, but where is all this late delivery going on?

So beware the following phrases from your teams:

* It should work: this usually means that it doesn't. It also means
that it was
probably not tested properly as the result is current undetermined. The
word "should"
should be taken out every developer's vocabulary - it either does or it
doesn't.

A very Boolean aproach to Management and a less than useful one, I think.
There are shades of grey. ("it either does or it doesn't...sometimes.) I
also take issue with the stated interpretations of "It should work..." The
two meanings given are far from being the only ones...

When support people tell me something should work, I answer "I know it SHOULD work. I
called you because it doesn't."


* Almost done: this is also a weasel word. When a developer tells you
things are
"almost done" ask for the specific tasks that are left over immediately.
In addition, keep
in mind that projects do not progress linearly - the last 10% is always
about 40-50% of
the work of the total project. I've seen projects that are chronically
late be "almost
done" for 3 months.

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.

* 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.

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.

* If things go smoothly: this I hear a lot, e.g. if we don't hit any
snags then we can
be done by Friday. Guess what - you're likelihood of hitting a "snag" by
next Friday is
probably high and given the lack of risk based management, the team has
probably got no
mitigation or contingency strategy. Then next week, you'll hear the next
phrase in our
list, "Yes, it could have been done if it weren't for that Snag we had".
* Yes, but, as in "Yes it can be done, but": this means it cannot be
done. Tell your
staff to just come clean and say, "No it cannot be done". Another variant
on this is, "Yes
it could have been done, if it weren't for marketing, requirements,
technical risk, etc."
This simply shows that your developers work in an idealistic world where
things never go
wrong.

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.

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.


* 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. My solution
is to assign low skilled interns and neophytes to the peripheral tasks such as
documentation, test plans, demo drivers, etc.

* I've got it done - I just need to integrate it: The word "Integrate"
is a big weasel
word. Think of a web service that adds two numbers together. The algorithm
is one line of
code. But the integration work is huge. In addition, integration usually
means the first
time that disparate teams are bringing code together which is always cause
for issues.
Don't under-estimate the integration, especially in today's world of
distributing
computing, web services, etc.

Yes, integration can be problematic. Nevertheless, it is still a fair
statement if the application is working. Again, "How long will it take to
integrate? What is problematic with the integration? Do you need help,
support, or tools to get it done faster?"

My solution to the integration problem is a pair of stub programs: a test caller and a
call receiver. You can write both in a few minutes. Prototypes attempt to do that but fall
short because they only check number and type of objects passed, not content.

* 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.

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. Someone should fix the root cause of 'incidents' so they don't happen again.

.