Re How competent are we

i am a member of the data processing dinosaur club; i learned the art of computer programming
in 1969 on a computer system used to kill people and to keep people from killing me, using
the most fundimental programming tools (buttons on the front of the box) and communicating
with the computer using it's own language... machine language.

i was taught cobol in an environment that i believed was common for the early '70s. i was
instructed in the skills required to turn a senior analysts design into an executable that would
produce the results specified in the design. technical knowledge of the computer system
was not required as an application programmer. and i was allowed two years to become
proficient with the language.

i have been listening to (and reading of) arguments for the elimination of cobol as a data
processing tool; most of the time in amusement, some times in disgust. i learn more of the
declining ability of people to communicate than i learn of the 'problems' and the 'solutions'.

management has been a problem from the time the position was created... in any department
or profession. management will be a problem as there are managers.

whenever you put those with one set of qualifications on a project requiring a different set
of qualifications the product will be something less than desired. again. in any department
or profession. from my experience as a junior programmer, as a p/a, in tech support, and yes;
as a project manager and dp manager, the area of qualifications (training) has and is the
root of all dp problems (problems that i/we have control of). and my experience was that
in this area the greatest returns on investment were achieved.

there is nothing 'bad' about cobol. it is a tool. it is more than adequate in doing what it was
designed to do. it and when it goes away it will do so because of 'political' considerations.
this is an open forum, but plese do not send me a twenty-page single-spaced list of things
that are wrong with cobol. any serious discussion on this subject would best be served if
held at your (or mine) favorite watering hole (with you buying)... and i drink a high-dollar
single-malt scotch. but i would much rather discuss...

1) the absence of sex in my life (leads to a more-enjoyable life)
2) free-form cobol (tremendous gains in productivity in this area)
3) skillset certification (a hard one to implement but would do wonders for the profession)
4) single-malt scotch

cobol has issues. identify. rectify.

___________________

it is hard to understand how some of the junk software on the market today is...
marketable. on those rare occasions that i dig into how the program is put together i am
left with a bad taste in my mouth at the sorry state of programming represented by
these programs. i finally came to understand the situation. what i see is a fresh graduate
of the cracker jack school of computer hacking, hired at a reduced rate by
a company driven by bottom-line rather that product quality, expected to produce a business
system using breaking-and-entering skills and tools. i am slowly learning to live in a world
of reduced expectations.
____________________

as always...
nice day here. hope yours is the same.

sss



--------------= Posted using GrabIt =----------------
------= Binary Usenet downloading made easy =---------
-= Get GrabIt for free from http://www.shemes.com/ =-

seasidesam <sam@seaside> wrote in message
news:28aad$48a8708c$62148bf3$10578@ALLTEL.NET...
>
> it is hard to understand how some of the junk software on the market today
is...
> marketable. on those rare occasions that i dig into how the program is
put together i am
> left with a bad taste in my mouth at the sorry state of programming
represented by
> these programs. i finally came to understand the situation. what i see
is a fresh graduate
> of the cracker jack school of computer hacking, hired at a reduced rate by
> a company driven by bottom-line rather that product quality, expected to
produce a business
> system using breaking-and-entering skills and tools. i am slowly learning
to live in a world
> of reduced expectations.
> ____________________
>

Walt Kelly used to have Pogo say something like "never atttribute to
malevolence what you can equally well attribute to stupidity".

My theory has always been that popular software is written by really
brilliant people fresh out of community college who, having no experience of
the real world, have no idea how a "good" program should act and how it
should be written. Certainly many of the bizarre choices that we have to
live with can be attributed to that.

PL

On Sun, 17 Aug 2008 23:09:39 -0500, "tlmfru" <lacey@mts.net> wrote:

>
>seasidesam <sam@seaside> wrote in message
>news:28aad$48a8708c$62148bf3$10578@ALLTEL.NET.. .
>>
>> it is hard to understand how some of the junk software on the market today
>is...
>> marketable. on those rare occasions that i dig into how the program is
>put together i am
>> left with a bad taste in my mouth at the sorry state of programming
>represented by
>> these programs. i finally came to understand the situation. what i see
>is a fresh graduate
>> of the cracker jack school of computer hacking, hired at a reduced rate by
>> a company driven by bottom-line rather that product quality, expected to
>produce a business
>> system using breaking-and-entering skills and tools. i am slowly learning
>to live in a world
>> of reduced expectations.
>> ____________________
>>
>
>Walt Kelly used to have Pogo say something like "never atttribute to
>malevolence what you can equally well attribute to stupidity".
>

The acutal statement is, "Never attribute to Malevolence what simple
Incompetence will explain." and it was written by Kellogg S. Booth
aka KS Booth.

>My theory has always been that popular software is written by really
>brilliant people fresh out of community college who, having no experience of
>the real world, have no idea how a "good" program should act and how it
>should be written. Certainly many of the bizarre choices that we have to
>live with can be attributed to that.
>

I agree. I'd hate to go back and look at some of the early IBM
Assembler and COBOL-D programs that I first wrote. I'm sure I'd deem
them as "bad" for a variety of reasons.

>PL
>

Regards,
////
(o o)
-oOO--(_)--OOo-

"Don't let Krusty's death get you down, boy.
People die all the time. Just like that.
Why, you could wake up dead tomorrow.
Well, good night."
-- Homer J. Simpson
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Remove nospam to email me.

Steve

On Mon, 18 Aug 2008 11:24:35 -0400 SkippyPB <swiegand@Nospam.neo.rr.com>
wrote:

:>I agree. I'd hate to go back and look at some of the early IBM
:>Assembler and COBOL-D programs that I first wrote. I'm sure I'd deem
:>them as "bad" for a variety of reasons.

ALTER GOTO is not intrinsically bad - if you do not have the memory it is
quite good.

--
Binyamin Dissen <bdissen@dissensoftware.com>
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

SkippyPB <swiegand@Nospam.neo.rr.com> wrote in message
news:to4ja4d9275knaikl7oqrdckrd57e8bi21@4ax.com...
> >My theory has always been that popular software is written by really
> >brilliant people fresh out of community college who, having no experience
of
> >the real world, have no idea how a "good" program should act and how it
> >should be written. Certainly many of the bizarre choices that we have to
> >live with can be attributed to that.
> >
>
> I agree. I'd hate to go back and look at some of the early IBM
> Assembler and COBOL-D programs that I first wrote. I'm sure I'd deem
> them as "bad" for a variety of reasons.
>

I bet, though (if you continued with Assembler), that once you got going you
produced programs that you can now review with pride and some nostalgia! In
those days of limited resources you really had to work at doing things and
making the most of what you had. I remember how pleased I was when I first
proved to myself that R13 could be used for cover as well as for the
register save area!

PL

On Mon, 18 Aug 2008 18:45:19 +0300, Binyamin Dissen
<postingid@dissensoftware.com> wrote:

>On Mon, 18 Aug 2008 11:24:35 -0400 SkippyPB <swiegand@Nospam.neo.rr.com>
>wrote:
>
>:>I agree. I'd hate to go back and look at some of the early IBM
>:>Assembler and COBOL-D programs that I first wrote. I'm sure I'd deem
>:>them as "bad" for a variety of reasons.
>
>ALTER GOTO is not intrinsically bad - if you do not have the memory it is
>quite good.

As someone who was infamous for using it in place of PERFORM to save
memory for programs running on a 32K model 30, I would hope there that
with more experience I could have found a better way. I had one
person tell my boss that he was worried because he was starting to
understand my payroll programs.

"Binyamin Dissen" <postingid@dissensoftware.com> wrote in message
news:376ja4t2hj1etj0263s1l49e46chv3u16n@4ax.com...
> On Mon, 18 Aug 2008 11:24:35 -0400 SkippyPB <swiegand@Nospam.neo.rr.com>
> wrote:
>
> :>I agree. I'd hate to go back and look at some of the early IBM
> :>Assembler and COBOL-D programs that I first wrote. I'm sure I'd deem
> :>them as "bad" for a variety of reasons.
>
> ALTER GOTO is not intrinsically bad - if you do not have the memory it is
> quite good.
>

I agree wholeheartedly, Binyamin.

In fact, there was a time (on a machine with very limited memory and
resources in general) when we found it indispensable.

And we didn't end up with a tangle of spaghetti, either. We simply devised a
few simple rules and stuck to them.

But, reading this thread of late, I find it quite saddening.

It seems like a bunch of grumpy old men grizzling about how awful their
management are and how their fantastic technical talent is/was so superior
to the youth of today but they never got to express it because they were
suppressed by short sighted administrators, blah, blah yada, yada....

Some samples taken from the thread:

"i have been listening to (and reading of) arguments for the elimination of
cobol as a data
processing tool; most of the time in amusement, some times in disgust. i
learn more of the
declining ability of people to communicate than i learn of the 'problems'
and the 'solutions'.

management has been a problem from the time the position was created... in
any department
or profession. management will be a problem as there are managers."

So, "management" are responsible for the decline of COBOL?

It had nothing to do with the rejection of OO COBOL by COBOL PROGRAMMERS?
(NOT managers...managers generally don't know enough about technology to be
able to accept or reject it...they use what they are told to use.) Had the
COBOL programming community embraced OO COBOL when it first came out, the
fate of COBOL may have been significantly different from what it is proving
to be... but, it is hypothetical, we'll never know...Certainly the OO
paradigm has been embraced by rest of the world and it is hard to imagine
serious computing in today's world without it.

The fact that the whole world has moved on and found better solutions more
appropriate to today's architectures is not considered. The fact that the
traditional rigid hierarchic structure of management is being subsumed in
more progressive companies by a networked management structure is also
conveniently overlooked. Just a total introspective focus on how good it was
and "poor me"...

.... Things are changing. I don't like change. There's no need for it to
change; I can handle it fine the way it is. Now I'm all bewildered by the
change. That's what you get when you let managers run things...

Sad.

Another one...

"My theory has always been that popular software is written by really
brilliant people fresh out of community college who, having no experience of
the real world, have no idea how a "good" program should act and how it
should be written. "

So you can't write good software unless you have years of experience?

Maybe... I would agree that experience certainly helps and most of us try to
make each program we write better than the last one we wrote (I do that
still today), but is it really fair to dismiss the youngsters coming out of
colleges today, having paid their dues, spent years of study and having had
to grapple with stuff that we never did, as if the only area they can be
faulted in is their lack of experience?

I have worked with several teams comprised of people like this and I have
been very impressed. These kids are smart, keen, and their attitude is
right. They are good at what they do (at least, the ones I've managed
were...). They are eager to learn and they are not living in "Glory Days".
Contrast that with some of the posts we are seeing here. And they have
experienced people placed with them so that both can benefit. It certainly
did me good to work with these teams.

Yes, there is good and bad software. Sometimes the assessment of it is
purely subjective and a package or program that one person finds abysmal,
someone else finds fantastic.

Yes, there are good and bad programmers. Always have been, always will be
(at least, as long as people are required to do programming...) It is the
diverse nature of Human Beings, not any particular suppression by
management, or lack of experience, or departure from the accepted norms of
1959 that causes the variation in software quality.

And yes, there are good and bad managers.

None of the above has anything significant to do with the decline of COBOL.

A stone adze was a reasonable tool for making a dugout canoe. A power tool
is better. That doesn't invalidate the stone adze.

(Of course, you might decide that, having a power tool, perhaps a dugout
canoe might not be the best way to cross the water, and so build something
completely different... Then you'll have wailing and gnashing of teeth at
the replacement of the dugout by the clinker built dinghy... it is the
nature of things.)

What the Hell is this exclusive club of "oldtimers" who were the only people
who ever wrote "good" software, who did it using good solid procedural COBOL
constructs (the ONLY way to program computers) , did it in spite of
horrendous know-nothing managers, and had the rug pulled out from under
their feet by a world that just doesn't get it...?

Take a look at yourselves.

It isn't pretty.

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

In article <5r3ka49hs105fu584l2ht84c4nl8ulqjrk@4ax.com>,
Clark F Morris <cfmpublic@ns.sympatico.ca> writes:
> On Mon, 18 Aug 2008 18:45:19 +0300, Binyamin Dissen
> <postingid@dissensoftware.com> wrote:
>
>>On Mon, 18 Aug 2008 11:24:35 -0400 SkippyPB <swiegand@Nospam.neo.rr.com>
>>wrote:
>>
>>:>I agree. I'd hate to go back and look at some of the early IBM
>>:>Assembler and COBOL-D programs that I first wrote. I'm sure I'd deem
>>:>them as "bad" for a variety of reasons.
>>
>>ALTER GOTO is not intrinsically bad - if you do not have the memory it is
>>quite good.
>
> As someone who was infamous for using it in place of PERFORM to save
> memory for programs running on a 32K model 30, I would hope there that
> with more experience I could have found a better way. I had one
> person tell my boss that he was worried because he was starting to
> understand my payroll programs.

As someone who was always rather proud of the COBOL I wrote, I was very
happy to visit a place I was stationed at while in the real Army (government
shop with relatively low turnover of employees) to see old freinds only to
find someone sitting at a desk with a listing of some COBOL I had written
almost 30 years ago that was still in production use.


bill

--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
billg999@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>

In article <6guo3sFhl7ohU1@mid.individual.net>,
Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote:

[snip]

>But, reading this thread of late, I find it quite saddening.
>
>It seems like a bunch of grumpy old men grizzling about how awful their
>management are and how their fantastic technical talent is/was so superior
>to the youth of today but they never got to express it because they were
>suppressed by short sighted administrators, blah, blah yada, yada....

Ahhhhh, for the Oldene Dayse... when a thread could be such, then, such as
*ten* threads cannot be, today! It could not be that folks on *all* sides
of a question could take this view, no.

Mr Dashwood, you've been predicting that COBOL will be gone for a while,
now... and universities have been dropping it from their curricula... and
businesses have not been training programmers in it... who else is there
to work in it but those who have a few years under their belts?

[snip]

>So, "management" are responsible for the decline of COBOL?
>
>It had nothing to do with the rejection of OO COBOL by COBOL PROGRAMMERS?
>(NOT managers...managers generally don't know enough about technology to be
>able to accept or reject it...they use what they are told to use.)

Mr Dashwood, last I looked Managers were responsible for 'the allocation,
co-ordination and motivation of personnel and resources towards the
accomplishment of a stated Executive goal'... are you now saying that
'COBOL PROGRAMMERS' (caps original) are responsible for the resources
accepted or rejected by their Managers? 'Tis, indeed, The World Turned
Upside-Down.

DD

<docdwarf@panix.com> wrote in message news:g8ega8$mq7$1@reader1.panix.com...
> In article <6guo3sFhl7ohU1@mid.individual.net>,
> Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote:
>
> [snip]
>
>>But, reading this thread of late, I find it quite saddening.
>>
>>It seems like a bunch of grumpy old men grizzling about how awful their
>>management are and how their fantastic technical talent is/was so superior
>>to the youth of today but they never got to express it because they were
>>suppressed by short sighted administrators, blah, blah yada, yada....
>
> Ahhhhh, for the Oldene Dayse... when a thread could be such, then, such as
> *ten* threads cannot be, today! It could not be that folks on *all* sides
> of a question could take this view, no.
>
> Mr Dashwood, you've been predicting that COBOL will be gone for a while,
> now... and universities have been dropping it from their curricula... and
> businesses have not been training programmers in it... who else is there
> to work in it but those who have a few years under their belts?
>

Sure. I have a few years under my belt myself. (And I have been working very
intensely in COBOL over the last few weeks).

But being old and being jaded or grumpy are not necessarily attributes that
can only exist together.

I'm just finding some of the posts here sad, that's all...

Actually, it is a good thing. I was wasting far too much time here and I now
realise that it is pretty pointless really. I always said when it stopped
being fun, I'd quit.

When it comes down to sad old men reliving Glory Days and blaming the rest
of the world for their current situation, I see no place for me in it.

There IS a place for war stories and old times, but that can't be ALL there
is...


> [snip]
>
>>So, "management" are responsible for the decline of COBOL?
>>
>>It had nothing to do with the rejection of OO COBOL by COBOL PROGRAMMERS?
>>(NOT managers...managers generally don't know enough about technology to
>>be
>>able to accept or reject it...they use what they are told to use.)
>
> Mr Dashwood, last I looked Managers were responsible for 'the allocation,
> co-ordination and motivation of personnel and resources towards the
> accomplishment of a stated Executive goal'...

(Hmmm.... smells like Nuremburg to me... "we just do as we're told, Guv..."
I don't think so.)

Anyway, that is only ONE definition, and it is just your usual boilerplate
trotted out by rote, without due thought. It is too vague to be applied to
this particular argument.

Even if it were true, it still doesn't alter the fact that it was the
obstinate resistance to change by people on the shop floor which caused the
failure of OO COBOL. The effects of that failure are becoming more and more
apparent and have consigned COBOL to a procedural backwater.

There is no coherent argument that can be made for the decline of COBOL
being caused by middle managers. They simply don't know enough. They
implement senior management policy which normally follows "fashion" or what
the opposition are doing, or what the vendor salesperson advises, UNLESS
there is a united groundswell of opinion from within the technical people.
If everyone in COBOL shops had been clamouring for the new technology,
middle managers would never have been able to stop it.The fact that most
people resisted it fiercely means you can't blame the management. They
actually went along with what the shop floor wanted.

> are you now saying that
> 'COBOL PROGRAMMERS' (caps original) are responsible for the resources
> accepted or rejected by their Managers?

Absolutely. Managers don't buy tools unless someone tells them to. Managers
don't implement technical approaches (like OOP) unless someone suggests it
could be a good (read, "money saving") idea... You know as well as I do that
most middle managers simply are not technically qualified to make such
decisions without advice from people who are so qualified. The programming
team as a combined unit have a large effect in determining technical policy,
standards, tools, and environments.

> 'Tis, indeed, The World Turned
> Upside-Down.

No it isn't. Management have ALWAYS had to be guided by technical
people.They buy advice if their own people are not capable of providing it ,
or have no credibility.

If their own people treat them with contempt, then those people are unlikely
to have much credibility. That's how you end up with "Airline Magazine"
management policies.

People may seldom get the managers they want (although I've been pretty
lucky in this regard... most of the people I've worked for have easily
earned my respect...), but they will very often get the managers they
deserve...

No-one has to tolerate bad management for any length of time. Either change
it, or work somewhere else where they appreciate you more.

Of course there are bad managers. I acknowledged that in my original, (which
you conveniently cut...)

What you do about your management may be the difference between enjoying
going to work or actually not doing so.

All I'm saying here is that they were not as responsibile for the decline
of COBOL as COBOL programmers were.

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