Re: J4 - presentation/discussion on "Future of the COBOL Standard"

"Robert" <no@[EMAIL PROTECTED]
> wrote in message 
news:otgqt3p795elql42v61deisgj6u9ncpnuf@[EMAIL PROTECTED]
> On Sun, 16 Mar 2008 12:01:28 +1300, "Pete Dashwood" 
> <dashwood@[EMAIL PROTECTED]
>
> wrote:
>
>>"Robert" <no@[EMAIL PROTECTED]
> wrote in message
>>news:n80nt3hh9uebhvl0g5knjnsmcdmfauj7o6@[EMAIL PROTECTED]
>
>>I saw your post where this had happened to you over a Business 
>>Requirement.
>>I strongly sup****t your desire for clear English.
>>
>>Your colleague(s) saw fit to re-write your SOR with more buzzwords and
>>jargon. This indicates that what you did was just too general or was
more
>>general than is normally the case on that site. Sometimes we use jargon
>>because it communicates unequivocally; sometimes it is just part of
>>protecting the mystique, in the interest of job security... :-)
>
> Technical language can give a false illusion of accuracy. My Business 
> Requirement is the
> fourth attempt to solve a problem. The first three were precisely
written 
> and implemented,
> but produced wrong answers because they made false assumptions about the

> real world.
> One assumption was that a US wireline telephone number can be 
> geographically located by
> taking the first six digits of the number and looking up the location of

> the central
> office containing the switch handling that exchange. Can you figure out 
> why that sometimes
> gives wrong answers? Hint: old numbers are in area code 909, medium aged

> ones are in 915,
> newer ones are in 951. The answer is not call forwarding nor foreign 
> exchange.
>
> Technical language is sometimes used to silence semi-technical subject 
> matter experts.
> When the problem is described in language they can understand, they 
> embarrass us by
> bringing up facts we don't know, for example legal issues. That's what 
> they're supposed to
> do. When the spec is in technical language, they agree to everything 
> rather than admit
> they don't understand it.
>
>>At the end of the day, it really doesn't matter what you or your
>>colleague(s) thought about your do***ent; what matters is what the
person
>>who had to use it thought. A Statement of Requirements needs to 
>>communicate
>>clearly. Using plain English is a good way to acomplish this (in fact, 
>>using
>>plain English is a good way to communicate in most situations...), but,
if
>>(and only if) the do***ent was perceived BY THE USER as failing to
>>communicate, or leaving things unclear, then it must be amended, or (and
>>preferably, in my opinion) some face to face discussion between the
author
>>and the user needs to take place.
>
> Face to face is impractical when parties are all over the planet.

I don't find it so. I talk face-to-face to people in NZ, Europe, the USA, 
and Australia every week. I use Skype video. The quality is excellent and 
it's free. (If anyone here would like a personal chat my Skype ID is 
"petedashwood"...)


>We do in-person meetings
> via NetMeeting and telephone.

Why use telephone when you can use video?

>When nontechnical management is involved, we add closed
> circuit TV.

Much better...


>NetMeeting has become the norm in large US companies. It is actually MORE
> effective than a conference room because everyone can SEE what you're 
> talking about.
> You're not limited to PowerPoint slides nor are you limited to text, as
in 
> this forum.
>

I agree NetMeeting is useful, although I haven't used it extensively.

> Take for example code review. In the old days it was done with hardcopy 
> listings and
> colored marker pens in a conference room. Now it is done with Beyond 
> Compare pointed at
> the code repository.

Is it? :-) I never heard of Beyond Compare so it obviously ISN'T in my 
world. However, I can guess what this tool does.

There is no need for code review if an Agile approach is adopted. Code 
either works or it doesn't and most of what is written won't be maintained

(I am NOT talking about COBOL development here). I find what you are 
describing "quaint"... :-) On the one hand, you sometimes belabour COBOL 
people for being stuck in the past, then you start talking about things
like 
"Statement of Requirements" do***ents, and "code review" which are 
techniques from the very era you despise...:-)

Could it be that you are bound by the sites you work on, just as the 
majority of the people here are?

>Participants, who are often in different cities or countries, are all
> looking at the leader's desktop (screen). When another participant wants

> to illustrate a
> technical point, the leader ****fts focus to that person's desktop.
>
> Conducting meetings in this environment requires virtuosity with
software 
> tools. Effective
> leaders do not fumble.
>

Facility with software is certainly a useful skill for anyone using 
computers to acquire, be they leader or follower...

>>If one of my colleagues picked up a do***ent of mine and started editing

>>it
>>to fit his own perceptions of how such a do***ent should be written, I'd
>>probably beat him about the head and neck with it :-). (Perhaps the 
>>implicit
>>recognition of this, is why no-one's ever done it... :-))
>>
>>Seriously, if someone felt the need to edit what I wrote, I'd definitely

>>sit
>>down and try to understand why they did.
>
> Turn on the audit feature in Word. They can even add sticky notes to 
> explain the rationale
> for a change.

I use it all the time when reviewing do***ents.
>
>>The need for written requirements is a hangover from the Waterfall and
is
>>more about "cover your arse" and control than it is about communicating.

>>In
>>more dynamic and fluid environments (like Agile...) face to face
>>communication trumps it easily. If you work in an environment where you
>>EXPECT requirements to change (even during development), and actually
>>WELCOME that change, you won't be writing down requirements. (You WILL
be
>>writing down timeboxed, prioritised goals (agreed jointly with the 
>>Business)
>>that will become deliverables out of the timebox...)
>
> All too often I work on code that lacks explanation of WHY it's doing 
> something. Sure, I
> can see WHAT it's doing, but that's not enough.

This has been a problem since people started programming computers. COBOL 
was an attempt to address it by using meaningful names and English-like 
verbs and syntax, but, as has been observed here before, some people can 
write Fortran in ANY language... :-)

It is only a problem if the code needs maintenance.

On non-OO COBOL sites (much more so than on sites where OO COBOL is used
as 
part of a component based approach), the code DOES need maintenance, so an

overview, background do***ent, or specific notes in the code itself need
to 
be provided. (One of the problems with all of these "good ideas" is that 
they require ongoing commitment and investment...If do***entation is not 
kept up to date, it is almost useless, and people have no faith in it, so 
don't use it. Pretty pointless writing do***ents that people can't/won't 
use... More modern approaches like Agile, simply obviate the need for it.


> I write comments to explain non-obvious
> background, sometimes whole paragraphs. On one project I put hot links
in 
> the code, tying
> it to the technical spec. The code reviewer deleted them, said they were

> "unprofessional".

It seems that "unprofessional" is a word that gets used a lot on the site 
where you work. Perhaps its use needs to be challenged. In what way is
tying 
code back to a tech spec. "unprofessional"?  It could be problematic if
the 
code gets changed and the tech spec. doesn't, but that is hardly a problem

of professionalism...Suppose it wasn't a hot link, just a reference; would

that be "unprofessional" too?

> I also linked the technical spec to the business spec. The do***entation

> reviewer deleted
> those links, for the same reason.
>
> Yeah, right. Mixed case code is still considered unprofessional in 
> mainframe shops. At
> least everyone knows it's a dying culture.

Maybe. As long as there are managers who see management as being about 
control, rather than facilitation, the culture won't die...
>
>>(I've just been writing about exactly this in the book I am fini****ng. 
>>There
>>is much more to it than I can elucidate here.)
>
> Beware of advocating 1990s ideas.

Me?! Never!!!... I liked the 60s... :-)

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