Re: S0C4 x'4' abend while reading VSAM KSDS file

On Mon, 30 Jun 2008 09:06:04 -0600, Howard Brazee <howard@xxxxxxxxxx> wrote:

On Fri, 27 Jun 2008 23:27:20 -0500, Robert <no@xxxxxx> wrote:

Every company thinks its BUSINESS problems are unique, but its computer problems are
routine. It's actually the other way around.

Programmers think programming problems are unique, salesmen think
sales problems are unique, managers think managing problems are
unique.

Can you provide evidence that your statement is the True
interpretation?

The opinion that counts comes from the business manager who makes funding decisions.

The real problem with Waterfall is not waste of time and money; the real problem is that
it prevents us from doing things right. It seems to prefer spending twice as much on
stopgap solutions.

It prevents which of us from doing things right?
How does it stop us from doing things right?

By refusing to fund development projects, while funding support efforts that cost twice as
much.

How do you define "right"?

Based on the merits of each case, rather than broad brush generalizations.

I have posted several times my opinion of "Righteous", and how easy it
is to decide that since My way is Right, other ways are all Wrong, and
subject to the consequences.

And as Jesus preferred being good to being right - I believe we should
measure business choices by their business results.

Spending twice as much is a bad business result.

Most of the world thinks Americans are dumb. New Zealand is no exception.

Cite?

Personal experience. Russians are the worst.

Foreigners (generally) value higher education more than Americans. A high percentage have
advanced degrees, and think it means something.

There must be a receptive audience for that idea, because I've been hearing it as long as
I can remember. In the 70s, 4GLs would eliminate programmers by GENERATING all the code.
In the 80s, 'your people' could do it themselves with Lotus or Excel macros, or with
Access. In the 90s, any chimpanzee could drag and drop widgets, VB or VC++ would spit out
the code.

The words change, but the melody remains the same. It's old wine in new bottles.

True. This is a process that didn't go exactly as predicted. How
productive are you today compared to how productive you were when you
started?

I'm somewhat more productive now. What's your point?

<laugh> Ever since Y2K, 50% is a starting point. Contracting companies aspire to get more.
I've told the story here about one who cried poor because it was making only 70 out of 120
bill rate. I know for a fact that IBM keeps 160 out of 200 bill rate.

Blended Rate is their favorite phrase. That means you pay the same for everyone, from
bunny to brain. Never mind that there are 50 bunnies for every brain.

Some people I know avoid spending that money by doing the head
hunters' work themselves. Most contractors find the money is not
worth that kind of work. Supply and demand.

Contractors who find their own gigs do much better financially AND get better projects.
I'd love to do that, but don't have the contacts. It works best when you specialize in one
industry. After awhile you get to know many decision makers.

Actually, it is done quickly. A typical six month project is timelined this way. Take away
planning from the front end, say two months. Take away testing and approval signatures
from the back end, say three months, although 3.5 is better because you don't know whether
the manager will be on vacation. Whatever is left in the middle is programming time.
Typically that's two weeks, although it is common for it to be 2-3 days. I've even seen it
go negative. But programmers are kept around and paid for six months, just in case
something goes wrong.

Management sees the bill and THINKS programming took the whole six months, when it
actually took two weeks.

It actually took the whole six months. Coding is the most trivial
part of the process of programming.

There is a great desire to trivialize programming ... by replacing programmers with code
generators, outsourcing the work to India, calling development an architectural process,
hiding code under multiple layers of abstraction, etc.

I recent development is using the programmer title for testers, production support and
they guy who stocks the Coke machine.
.