Stop Finding Fault and Fix the problem!

Stop Finding Fault and Fix the problem!

Post by Jeff Kennedy, Systems Programmer,CERTCO,INC » Wed, 30 Jul 1997 04:00:00






> >> comp.software.year.2000.insults
> >> comp.software.year.2000.doomngloom
> >> comp.software.year.2000.*
> >> comp.software.year.2000.humour (or .humor if you prefer)
> >> comp.software.year.2000.technical
> >> comp.software.year.2000.employment

>    comp.software.year-2000.lou

you sure there isn't a size limit on ng's.  That last one would surely
bring the internet to it's knees.

ROFL

Pat

 
 
 

Stop Finding Fault and Fix the problem!

Post by Jeff Kennedy, Systems Programmer,CERTCO,INC » Wed, 30 Jul 1997 04:00:00





> >> comp.software.year.2000.insults
> >> comp.software.year.2000.doomngloom
> >> comp.software.year.2000.*
> >> comp.software.year.2000.humour (or .humor if you prefer)
> >> comp.software.year.2000.technical
> >> comp.software.year.2000.employment

>    comp.software.year-2000.lou

you sure there isn't a size limit on ng's.  That last one would surely
bring the internet to it's knees.

ROFL

Pat

 
 
 

Stop Finding Fault and Fix the problem!

Post by Eric Buckle » Wed, 30 Jul 1997 04:00:00


<snip>

Quote:> But  does it really matter how we describe it or try to put it in a box
> with a label?  The important thing is just get it done, NOW!!!  Spending
> our time arguing or even discussing the issue doesn't solve the problem.

Are you suggesting that a discussion of project management methods is
futile or are you talking about placing blame? This thread is just
starting to get relevant.

My management experience is primarily in client/server development. One
of the main reasons those projects fail (aside from being poorly
staffed) is that they are managed with the traditional waterfall
methodologies. That works OK for batch processing or highly repetetive
data entry, but is lousy for highly interactive systems. The reason is
that data flows can generally be described correctly by users, but when
it comes to user interaction the attitude is more "I'll know it when I
see it."

Y2K is neither of these situations. The data flows and user interactions
are already known. One might be tempted to get right to work fixing
code. However, we have seen on several projects now that some analysis
and planning can remove many potholes from the road before they knock
the project out of alignment.

I am not advocating using the waterfall. We had most of the code
analyzed before the inventory was complete. And we were fixing code
before all the analysis was done. Some fixes will be back in production
before others are even addressed. The reason we can do this is because
we took a close look at the dependencies between applications prior to
scheduling the work. My current project had very few dependencies. That
allowed us to work very quickly and adjust easily when a task got held
up. The systems on the mainframe side have many more dependencies, so
their work looks a little more like a waterfall. They have still been
able to segment the work enough that they can fix/test/release systems
in batches rather than trying to do each phase in its entirety. This has
permitted them to also work around resource shortages and delays in
acquiring a test platform.

Quote:> 876 days to go [521 if you want to be finished by 1/1/1999].

All the more reason to check the map. You can't afford to get lost on
this one.
________________________
Eric Buckley
Comsys Millenium Services
eMail: remove NoSpam from above
Standard disclaimer - I speak for myself and nobody else.
 
 
 

Stop Finding Fault and Fix the problem!

Post by Bill H » Wed, 30 Jul 1997 04:00:00



> Couldn't agree more.
[snip]
> time to get going NOW !
> --


[snip]
> > spend all our time discussing why it happened, we will find that very
> > soon, there is no more time!  So let's stop wasting time arguing why
[snip]
> > There may not be enough time left to fix all the systems, but let's try
[snip]
> > we can sit around twiddling our thumbs discussing why we got into
> > this mess in the first place.

> > John Blackburn

Guys, tell this to the employers, we know the problem needs
fixing now.
As long as they continue to be asleep at the switch or claim
they can't find the required talent, we can't do anything.
Ignoring the many resumes I've sent, the 20+ years Cobol and
12 years mainframe is their fault, not mine.
If they continue to ignore these kinds of resumes, where the
applicant is obviously over the age of 45/50, who's to blame?
I'm sure I'm not the only one in this NG facing this attitude.
I wouldn't mind working on it, but in the interim, I'm sitting
here twiddling my thumbs.
zzzzz twiddle zzzzz in Canada.
Bill H.
 
 
 

Stop Finding Fault and Fix the problem!

Post by cory hamasa » Thu, 31 Jul 1997 04:00:00



Quote:

>Guys, tell this to the employers, we know the problem needs
>fixing now.
>As long as they continue to be asleep at the switch or claim
>they can't find the required talent, we can't do anything.
>Ignoring the many resumes I've sent, the 20+ years Cobol and
>12 years mainframe is their fault, not mine.
>If they continue to ignore these kinds of resumes, where the
>applicant is obviously over the age of 45/50, who's to blame?
>I'm sure I'm not the only one in this NG facing this attitude.
>I wouldn't mind working on it, but in the interim, I'm sitting
>here twiddling my thumbs.
>zzzzz twiddle zzzzz in Canada.
>Bill H.

Y2K remediation will never be as cheap as it is today.  What do
they think will happen?  Some university will graduate ten
thousand kids with 6 COBOL classes, VSAM I and VSAM II, a year of
JCL, and two years of CICS?  It's not going to happen.

Even ten thousand isn't enough, there are fifty thousand
S/370-S/390 mainframes in the world.

Do they think they'll find a secret stash of geeks with 5 solid
years of COBOL and CICS who will work for $55,000/year?   It's
not going to happen.

There's 885 days left!

Don't sleep, Bill, polish up your skills.  In the last year, I
put up a bunch of ISPF panels that interact with Rexx.  Played
with CA-7 (what a screwy product.)  TSO, ran batch jobs on a
client's ES9000 and my OPEN/370, got some COBOL tips from the
gang over in comp.lang.cobol.

I also did a lot of C/C++ coding using CSet++ on OS/2 V3 and V4
so I'm covering myself.

Cory Hamasaki  

 
 
 

Stop Finding Fault and Fix the problem!

Post by David K. Brya » Thu, 31 Jul 1997 04:00:00




>> But  does it really matter how we describe it or try to put it in a box
>> with a label?  The important thing is just get it done, NOW!!!  Spending
>> our time arguing or even discussing the issue doesn't solve the problem.
>Are you suggesting that a discussion of project management methods is
>futile or are you talking about placing blame?

I begin my big Y2k project on Monday.  It starts off with
a meeting with the client.  They have already indicated
that they want to see a project plan, testing plan, status
reports, data file inventories, program file inventories,
impact analysis, yada, yada, yada.

Sounds like they want something for the bookshelf that
documents the failure of their project rather than a
realistic possibility of success.

 
 
 

Stop Finding Fault and Fix the problem!

Post by Eric Buckle » Thu, 31 Jul 1997 04:00:00



> I begin my big Y2k project on Monday.  It starts off with
> a meeting with the client.  They have already indicated
> that they want to see a project plan, testing plan, status
> reports, data file inventories, program file inventories,
> impact analysis, yada, yada, yada.

We've provided all that. It's really not that big of a deal. Just don't
use any programmer talent on this. A project admin is a *lot* cheaper
than a code cranker (not to mention easier to find.)

The project plan is obvious - you have to do that. Same can be said for
the test plan and the inventories. Without those you really will fail.
Make sure you build in time for new development. Don't assume that code
being written today is compliant. On my current project, we've handled
all the existing code. The main task now is setting up a review
procedure so the new stuff doesn't*it all up again.

Status reports can be huge time wasters. I don't let programmers do
status reports. I just ask them what they're up to and write it up
myself. Fortunately, this is the type of project where you can get some
pretty good feedback on where people are. They've either looked at a
file or they haven't. Not much room for dancing around an issue.

Impact analysis is the biggest waste. Avoid it if at all possible. If
the program is compliant, there's no impact. If not, it will fail. You
may want to make some triage decisions, but basically this is a no
brainer. Yet I see many organizations spending a lot of time on this. I
don't get it. Start fixing the most important stuff first. If you get it
all done early (as we did) great. Shut down the project and save some
money.

Quote:> Sounds like they want something for the bookshelf that
> documents the failure of their project rather than a
> realistic possibility of success.

They're probably just looking for ammunition for when they tell the CEO
how much it's going to cost. That's their problem. Give them the
absolute minimum and let them ask questions if they want more.
________________________
Eric Buckley
Comsys Millenium Services
eMail: remove NoSpam from above
Standard disclaimer - I speak for myself and nobody else.