Re: Do you have a Knowledge Officer?

On 29 Sep, 21:39, Robert <n...@e.mail> wrote:
> On Sat, 29 Sep 2007 10:28:24 -0700, Alistair <alist...@ld50macca.demon.co.
uk> wrote:
> 
>
> Wrong. Every line of code can be traced back through a Detailed Design and
 High Level
> Design to a  Business Requirement. And it can be traced forward through as
 many levels of
> test results all the way to a User Acceptance Test.

I hope that was said with your tongue in your ch. I can assure you
that many systems that I have worked in did not maintain documentation
after release and, therefore, the only reliable documentation was the
code. And where that says things like 'remove after 1984' (in code
being maintained in 1997) or 'I dont know what this does so I left it
in. If you have got this far then you are a braver man than I am'!

>
>
> THEY wrote the code. Don't they talk to each other?

IT people are world renowned for their inability to communicate in
clear to any but techies.

> 
>
> How long does it take to write a PERL script to discard  bad transactions?

Pearl? Wazzat? Does it run on Big Iron?

>
> I once naively suggested we should at least save employee numbers from the
 paychecks we
> were deleting. The scornful answer was "We don't have time for that. Let t
hem complain
> through the chain of command." Whoops, excuuse me.

On Tue, 02 Oct 2007 12:52:08 -0700, Alistair <alistair@ld50macca.demon.co.uk
> wrote:

>On 29 Sep, 21:39, Robert <n...@e.mail> wrote: 
>
>I hope that was said with your tongue in your ch. I can assure you
>that many systems that I have worked in did not maintain documentation
>after release and, therefore, the only reliable documentation was the
>code.

You want documentation to be a single document, but you have no mechanism to
 assure its
maintenance. Management sees documentation as a string of change reports. In
 big (F-100)
companies, they DO have a mechanism to assure it is completed for each chang
e. The goal is
not a reference for future changes, it is a checklist to avoid errors and om
issions in the
current change cycle.

> And where that says things like 'remove after 1984' (in code
>being maintained in 1997) or 'I dont know what this does so I left it
>in. If you have got this far then you are a braver man than I am'!

It shouldn't be a comment. It should be an IF statement or, better yet, cond
itional
compilation.
 
>
>IT people are world renowned for their inability to communicate in
>clear to any but techies.

That's the stereotype; it doesn't agree with my experience. An estimated 10%
 of the people
I've worked with were gs. Generally, they're not as good as they see them
selves. The
very best programmers seem normal, not gy. The only hint is rapid speech,
 finishing
your sentences for you, and doing things on the computer ten times faster th
an normal.

The fastest way to evaluate programmers is to glance at a page of their code
. Any code.
 
>
>Pearl? Wazzat? Does it run on Big Iron?

Sure. When running Linux, it acts like a normal computer. :)

On Thu, 04 Oct 2007 13:10:49 -0700, Alistair <alistair@ld50macca.demon.co.uk
> wrote:

>On 3 Oct, 03:36, Robert <n...@e.mail> wrote: 
>
>Spot on. Yes. Absolutely. Too true.

There should be at least five documents or, ideally, an outliner that allows
 hiding and
revealing lower levels. The levels are: business plan, business requirement,
 high level
design, detailed design and source code. There should also be links to execu
tion logs,
incident reports and usage statistics.

The document you have in mind is detailed design, which is fine for techies 
but useless to
management.

 
>
>Perhaps we should have a universal standard throughout all IT
>organisations for documentation standards particularly dealing with
>maintainance/support requests.

There is a de facto standard. It goes by various names such as ISO-9000, CMM
 and SDLC; in
practice, they're pretty much the same.

>Unfortunately, I have only worked in
>the real world and have only been exposed to documentation that is
>either non-existant, omits by default or merely lies.

It's not the real world where big companies live; it's the world of undiscip
lined IT
shops.

I recommend you visit a big company and ask to see the documentation framewo
rk for a
typical project, start to finish. It's very different from the world where y
our company
lives.
 
>
>The goal is for documentation that reflects the status/structure of
>the system ACCURATELY. (with or without two Rs).

Evidence of accuracy is minutes of meetings that examined it line by line, r
epeated until
all parties agree (typically 3-5 iterations), signed by all involved. At my 
current
employer, every line of documentation and code is inspected by about ten peo
ple. It
doesn't take as long as you'd think. No objections or questions are dismisse
d or ignored.
We do it electronically, using voice phone and Netmeeting displaying  the le
ader's
desktop. Participants are all over the world.

We have more than a thousand development projects going. Could your company'
s methodology
handle more than ten?
 
>
>It does with mine.
> 
>
>You have worked with some people who, clearly, are in need of
>psychiatric help.

You've seen celebrities such as Torvalds, Andreessen, Cowlishaw, Montulli, C
utler, etc. Do
they seem psychotics or personality defectives?
 
>
>That is subjective.

It's much more accurate than talking to them.

I once worked for a company that had 20 world-class programmers. I went arou
nd asking
who's the best, expecting each to name himself. Surprisingly, they all point
ed to the same
quiet high school student who worked there part time, looked like a Boy Scou
t and was a
devout Mormon. I said that's impossible. They said look at his code. I did. 
They were
right. A few seconds of code inspection told me more than months of conversa
tion.

On Thu, 04 Oct 2007 20:29:07 -0500, Robert <no@e.mail> wrote:

>
>There should be at least five documents or, ideally, an outliner that allow
s hiding and
>revealing lower levels. The levels are: business plan, business requirement
, high level
>design, detailed design and source code.

The hard part about these is that we want to be able to trust all of
that documentation to be currently accurate.

Robert <no@e.mail> wrote in message
 news:190bg3l4erp8cpqoe80tgjsbhagb2mg674@
4ax.com...
>
> There should be at least five documents or, ideally, an outliner that
allows hiding and
> revealing lower levels. The levels are: business plan, business
requirement, high level
> design, detailed design and source code. There should also be links to
execution logs,
> incident reports and usage statistics.
>
> The document you have in mind is detailed design, which is fine for
techies but useless to
> management.
>
>

So far as the detailed design document is concerned -

I've long been of the opinion that it ought to be possible to design a
universal specifications language - universal in terms of application
programming, anyway - that is completely language and platform agnostic,
that contains basic, common "instructions" and allows for custom code
modules, that will generate code in any source language desired.  I know
there have been many approaches to this, from the FARGO report generator on
the IBM 1401 to the most sophisticated tools available today - but I don't
think there is any product that will allow complete code independence and
mandate changes to be implemented by changing the specs, at the same time
being adequate for all applications (a very imprecise requirement, I admit,
but I have to say something!)

I'd be interested in hearing of counter-examples!  One man's experience is
never adequate.

I did some development on my own time on such a system and it seemed to
indicate that a very small set of intrinsic functions or operators ("atomic"
in that they couldn't be expressed by combining other functions) - perhaps
30 or so - along with a few higher-level "verbs" such as as table lookup
(again a rather small number) combined with custom code segments that would
be accessed by a "custom verb" - would suffice for any application situation
that I could think of.  I make no apology for the "custom code" idea,
because every language has "call-out" facilities, and if you don't have that
you must define verbs peculiar to the language to allow for them - a futile
effort.  Given such a tool, a system defined in the spec language could be
generated in any desired target language to experiment with speed or
footprint issues - source code maintenance would no longer be a problem
since it wouldn't be done -  or, by changing the underlying generating
dataset, even different techniques in the same langauge could be compared.

Unfortunately I never had the time or resources to get very far with it.

PL

In article <BMuNi.3425$bM6.496@newsfe20.lga>, tlmfru <lacey@mts.net> wrote:

[snip]

>One man's experience is never adequate.

Oh, I *cannot* resist...

... seems like I've seen different attitudes manifested, say, by Mr
Wagner.

DD

<docdwarf@panix.com> wrote in message news:fe5uol$k5b$1@reader1.panix.com...
> In article <BMuNi.3425$bM6.496@newsfe20.lga>, tlmfru <lacey@mts.net>
> wrote:
>
> [snip]
> 
>
> Oh, I *cannot* resist...
>
> ... seems like I've seen different attitudes manifested, say, by Mr
> Wagner.
>

Why pick on Robert? You youself have manifested such an attitude, as,
indeed, have I.

We all relate to our own experience; there's nothing wrong with that.

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

"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
news:5mntnsFefolrU1@mid.individual.net...
>
>
> <docdwarf@panix.com> wrote in message news:fe5uol$k5b$1@reader1.panix.com.
. 
>
> Why pick on Robert? You youself have manifested such an attitude, as, inde
ed,
> have I.
>
> We all relate to our own experience; there's nothing wrong with that.
>
> Pete.
> --
> "I used to write COBOL...now I can do anything."
>
>
Pete,
It seems to me that you, DD, I, and MOST of us USUALLY qualify our statement
s
with phrases such as " in my experience" or "from what I have seen".  This i
s in
stark opposition to how RW usually (not always) makes his statements.  I bel
ieve
that he has even stated that something along the lines of "of course I am
expressing my opinion or my experience" and seems to expect us to "infer" th
ese
qualifications.  As I have stated repeatedly, if he would qualify his statem
ents
then (at least I - and I suspect others) would more easily respond to the
content rather than the tone of his posts.

(See for example, the recent notes on US government agencies and mainframes.
Compare his original wording with his later qualification - and then try to
apply his qualifications TO the way the original statement was worded.)

--
Bill Klein
wmklein <at> ix.netcom.com

On Fri, 05 Oct 2007 23:22:45 GMT, "William M. Klein" <wmklein@nospam.netcom.
com> wrote:

>
>"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
>news:5mntnsFefolrU1@mid.individual.net... 
>Pete,
>  It seems to me that you, DD, I, and MOST of us USUALLY qualify our statem
ents
>with phrases such as " in my experience" or "from what I have seen".  This 
is in
>stark opposition to how RW usually (not always) makes his statements.  I be
lieve
>that he has even stated that something along the lines of "of course I am
>expressing my opinion or my experience" and seems to expect us to "infer" t
hese
>qualifications.

It is common for CLC  postings to state a conclusion, unsupported by facts/p
remises and
the canons of logic, much less citations. In those cases, added qualifiers d
oesn't change
the opinions' essence, they just make the writer sound like a bureaucrat.

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

---  Quotations ---
Weasel words are almost always intended to deceive or draw attention from so
mething 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.

Generalization by means of grammatical quantifiers (few, many, people, etc.)
, as well as
the passive voice ("it has been decided") are also part of weasel wording. G
eneralization
in this way helps speakers or writers disappear in the crowd and thus disown
responsibility for what they have said.

http://en.wikipedia.org/wiki/Weasel_word

Weasel-Words Rip My Flesh!Spotting a bogus trend story on Page One of today'
s New York
Times.
By Jack Shafer
Posted Tuesday, Sept. 20, 2005, at 6:38 PM ET

How many "many's" are too many for one news story?

Like its fellow weasel-words—some, few, often, seems, likely, more—many serv
es writers who
haven't found the data to support their argument. A light splash of weasel-w
ords in a news
story is acceptable if only because journalism is not an exact science and d
eadlines must
be observed. But when a reporter pours a whole jug of weasel-words into a pi
ece, as Louise
Story does on Page One of today's (Sept. 20) New York Times in "Many Women a
t Elite
Colleges Set Career Path to Motherhood," she needlessly exposes one of the t
rade's
best-kept secrets for all to see. She deserves a w in the stockades. And 
her editor
deserves a month.

Story uses the particularly useful weasel-word "many" 12 times—including onc
e in the
headline—to illustrate the emerging trend of Ivy League-class women who atte
nd top schools
but have no intention of assuming the careers they prepared for.

She informs readers that "many of these women" being groomed for the occupat
ional elite
"say that is not what they want." She repeats the weasel-word three more tim
es in the next
two paragraphs and returns to it whenever she needs to express impressive qu
antity but has
no real numbers. ....None of these many's quantify anything. You could as ea
sily
substitute the word some for every many and not gain or lose any information
. Or
substitute the word few and lose only the wind in Story's sails. By fudging 
the available
facts with weasel-words, Story makes a flaccid concept stand up—as long as n
obody examines
it closely.

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 chron
ic late
delivery and poor quality.

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 does
n't.
* I just need: beware of that word "just". Its a belittling word meant to ma
ke things
smaller than they are. Just take the phrase "I just need to write this compo
nent" to be "I
need to write this component" and already the magnitude of the work involved
 grows.
Developers tend to be chronic under-estimators and the use of the word "just
" is a sign of
that mentality.
* 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 abou
t 40-50% of
the work of the total project. I've seen projects that are chronically late 
be "almost
done" for 3 months.
* It was tested: this also usually means it that wasn't tested properly. Ask
 for a
test plan and the specific tests that were done. If the developer cannot pro
duce these
with sufficient evidence that PROVES that it was tested, then it wasn't test
ed.
* It must be an environment/configuration/deployment problem: this may be ac
tually
true, but it usually points to a larger stability problem. If you cannot bui
ld and deploy
reliably then why would you have confidence that the code works?
* If things go smoothly: this I hear a lot, e.g. if we don't hit any snags t
hen we can
be done by Friday. Guess what - you're likelihood of hitting a "snag" by nex
t Friday is
probably high and given the lack of risk based management, the team has prob
ably got no
mitigation or contingency strategy. Then next w, you'll hear the next phr
ase 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. T
ell 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, technica
l risk, etc."
This simply shows that your developers work in an idealistic world where thi
ngs never go
wrong.
* We'll make up the time at the end: if you're already late by the end of
requirements, you're likely going to be even later by the end if you simply 
keep going on
the same track. In my experience, teams don't dramatically faster as they hi
t their
stride. Even if there is some efficiency, its nowhere enough to make up for 
lost time.
* 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 test
s, etc. so
that code is visible as soon as possible. Use slicing models so that you can
 see pieces of
the application in ws, not months. In addition, code that isn't checked i
n should never
be counted - that means that someone cannot build it sufficiently to share i
t. It only
counts if you can verify it. Ideally, its not "done" unless there are suffic
ient unit
tests, a build script, and a document that someone walking into the code rep
ository could
check out the project run a build and have all the unit tests pass. Then the
 code is done
- anything less is mythical.
* 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 i
s one line of
code. But the integration work is huge. In addition, integration usually mea
ns the first
time that disparate teams are bringing code together which is always cause f
or issues.
Don't under-estimate the integration, especially in today's world of distrib
uting
computing, web services, etc.
* It Worked on my Machine!: programmers use this excuse to downplay a bug. T
he 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 yeste
rday", "That
must be a data problem", etc. is admitting you have a bug that cannot be eas
ily
duplicated.

My recommendations to reduce the amount of excuse making from your team:

* Encourage a culture of honesty and team work: You get these excuses when d
evelopers
are hiding things, and sometimes this is because you've created a culture th
at encourages
hiding because you don't want an honest answer.
* Be ruthless with your quality and talent standards: don't excuse poor tale
nt, bad
management or chronic late delivery. If you create a culture where talent is
n't rewarded
the bar isn't kept high then you'll be excusing the team to continually stri
ve for
excellence.
* Expect more than just code: measure performance based on estimation, quali
ty,
delivery and team work as well as pure code quality. If you have a developer
 who produces
great code but cannot deliver on time then that's not a great developer.
* Increase visibility and shrink delivery cycles: if you have to show your w
ork on a
constant basis and deliver on 2 w iteration cycles, your excuses tend to 
go away. You
either deliver or you get found out pretty quickly. Use show and tells, code
 reviews and
continuous integration to see what people are doing on a constant basis.
* Don't give half credit for 50% done - its either done or not done: If your
 tasks
cannot be managed this way, then you should split up your tasks until you ca
n work this
way.
* Establish what "Done" really means: for example, at a minimum "Done" shoul
d mean
checked into source code control and able to build into the current branch. 
If you're
doing Test Driven Development, it should also mean all tests run successfull
y. If you have
specific performance criteria, then its not "Done" until the performance tes
ts pass.
* Use counting techniques to measure wherever possible: this is a great sugg
estion
from McConnell's book on estimation. The more you can count in units, the mo
re accurate
you estimation. So if you can count the number of pages, web services, objec
ts, databases,
tables, stored procedures, tasks, etc. that are left to accomplish then you 
can measure
them more easily than if its a big blob of work. If your requirements aren't
 well defined
enough to count objects, e.g. you don't know how many web pages you're build
ing in your
web site, then you're really not in a position to estimate your ship date.
* Don't sucker, manipulate or bully your team: If as a project manager, you 
resort to
traditional management tactics such as playing games, being political, estab
lishing a
blame culture, or bullying your team you'll lose your credibility and simply
 encourage
lying. A tortured prisoner will tell you anything you want to hear - the sam
e goes with
development teams.

If you have a project that operates in the open, has a culture of honesty an
d establishes
a high performance bar, you'll find that peer pressure as well as some overa
ll guidance
will get risks, problems and bugs out in the open. If when you discover thes
e problems
people work as a team to fix them instead of blaming each other then every p
roblem solved
becomes a victory and not a blame opportunity. You'll get better answers and
 improved
morale on the team as you set clearer performance expectations.

http://chriswoodill.blogspot.com/20...asel-words.html

"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:8HzNi.253052$1o1.247940@fe12.news.easynews.com...
>
> "Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
> news:5mntnsFefolrU1@mid.individual.net... 
> Pete,
>  It seems to me that you, DD, I, and MOST of us USUALLY qualify our
> statements with phrases such as " in my experience" or "from what I have
> seen".  This is in stark opposition to how RW usually (not always) makes
> his statements.  I believe that he has even stated that something along
> the lines of "of course I am expressing my opinion or my experience" and
> seems to expect us to "infer" these qualifications.  As I have stated
> repeatedly, if he would qualify his statements then (at least I - and I
> suspect others) would more easily respond to the content rather than the
> tone of his posts.

I wish the Doc would stop calling me "Mister", but I don't let it blind me
to his posts. (I understand he needs to do so... diversity.)
>
> (See for example, the recent notes on US government agencies and
> mainframes. Compare his original wording with his later qualification -
> and then try to apply his qualifications TO the way the original statement
> was worded.)
>
He posted, got taken to task, modified what he'd said. What more do you
want?

Robert (and I don't want to talk about him like he isn't here...) is who he
is, just like all of us. Different personalities, different experience, even
different cultures.  Diversity is a very good thing in any group.

If we had a Klingon posting here, would you be offended by the agressive
tone of the posts? :-)

I noticed your insistence regarding the 9+ years statement :-) Frankly, it
says more about you than it does about Robert, Bill.

Does anyone really give a rats arse whether he has 9+ or 5 or 7 or 3 years
with Unix? So he exaggerated (maybe... his explanation seemed reasonable to
me) in the heat of the moment. It doesn't matter. That's the kind of guy he
is.

Would you demand an overnight personality change so he can post in CLC
without offending anybody :-)?

Give it time. :-)

The fact is that Robert HAS taken on board some of what has been said here.
(You acknowledge this with your "(not always)" above.) Robert can correct me
if I'm wrong, but I think he has also realised that there are people here
who can actually contribute something worthwhile, even if arguing with him,
and he can learn something by being here. (All of us together are more
useful than any one of us alone...)

Can you honestly say that his contributions here have been TOTALLY
worthless...?  (I agree there is chaff with the wheat, but you won't catch
me queuing up to throw stones on that score :-))

If you find that his posts merely irritate you and you get nothing from them
then there are a number of options open to you. That is entirely a matter
for you.

Me, I find all the posts here (even the ones that sometimes itrritate me
intensely :-)) to be at least entertaining, if not always informative.

It's only USENET, Bill, not the United Nations...:-)

A few years back a group of people ganged up on you and tried to discredit
what you said. (I might add in passing here that I have nothing but respect
and regard for you.)  I defended you vehemently and publicly then, because
it was completely unfair, and I believed your contributions were very
worthwhile.

I made this post for similar reasons.

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