Re: CODE/400 -- MIDRANGE-L

** Reply to note from Buck Calabro <mcalabro@commsoft.net> Tue, 3 Mar 1998 
10:21:04 -0500

> On the other hand, it seems that you're rather missing the point:
> Don't think like a programmer, think like a manager!

Well, from the posts on this list, I'll sure take that as a compliment!

> Clearly, management is NOT going to give you anything and
> everything you want simply because you ask for it.  You need
> to justify your need---agreed?

Absolutely!

> If I recall, you're in Vegas.  There's lots of money there, and perhaps
> your management is somewhat less concerned about absolutely
> minimising expenses.  Here in the Rust Belt, things are tighter.  We
> don't get to spend money without serious management debate.

Last October I accepted a job here in Folsom, California. This has turned
out to be far, far better than I imagined before the move. 

But, back to subject...

> When I present the case for Code/400, this debate has several
> facets:
> 1. The fact of the up-front expense that must be booked now.
> 2. My opinion, strongly in favour.
> 3. Possible, unmeasurable productivity gains in the future.
> 4. Other shop's opinions, for or against.  (References)
>   
> Of these factors, only #1 is quantifiable.  The rest are all subjective.

Not so! It is very easy to quantify the "Possible" gains. If you are going
to shoot for an objective, see what that is worth. 

Now, if your manager has a backlog, or is hiring, then you need to compare
the cost of Code/400 against the value of reducing the backlog at a
greater rate, or the cost of the programmers you want to hire.

Now, suppose you could increase the productivity of the staff by 20
percent. Take twenty percent of the salaries, benefits, floor space,
hardware, etc. costs of employing staff. 

Now, you can look at what the potential ROI is. Now, as you and your
manager know, there is no guarantee of that return (I may believe it is
guaranteed, but you guys have yet to see it). So, the question is whether
or not the risk is worth it. 

Let's take a shop with 20 programmers costing around $60k annual (which
is fairly cheap for total cost of a programmer). So, we are comparing a
risk of $6,000 (cost of two seats plus salaries and support for two weeks
for two staff) against a gain of $240,000 annual return. 

Then, after you look at it you realize that you can, in all probability,
find a way to insure that you will not need to pay for the licenses unless
you intend to keep them (ie., the project is a success) and that the two
employees will probably know within a week if the product is a total wash
out. If the product isn't a wash out but doesn't pay off, there will not
be two weeks of work lost (after all, the point is for them to be USING
the product for the two weeks). So, the actual risk in really evaluating
the product is about $2000 or less than one percent of the potential
annual return. 

> As to the potential productivity gains, there may well be ammunition
> as yet undiscovered to use on that front.  Things like "before and
> after" numbers and specific things that the Code/400 product does
> that are far superior to SEU/PDM/ISDB.

When I managed a small shop in Las Vegas, I had accumulated a number of
software issues from our customers. I was pretty familiar with how long
certain things took. As you know, you can never really exactly quantify
the fix time for bugs, but you can have a good idea. 

I installed Code/400 and set it up on the workstations myself. I wanted it
to be easy for the programmers to start using it, so I created the
projects, etc. so they could find code by just pointing and clicking. Day
1, they simply started using LPEX instead of SEU. Almost zero productivity
change (on one hand, they weren't using any features of LPEX, but on the
other hand they were working as fast as they did before). By the end of
the first week I was noticing a significant improvement in some tasks.
This was a result of the programmers starting to use the features of LPEX.
I was pleased and decided that it was going to be well worth the money.

During week two, as the programmers were really starting to go with the
product (although one of them insisted on keeping the keyboard set with
SEU keymap), I demonstrated the use of the debugger every now and then. I
didn't tell anyone to use it, but rather when we would be discussing an
issue, I'd pop up the debugger and have a look. 

They loved it. It took off, I have evangalized ever since. I had used the
product before that, but that was when I got the chance to see how much
difference it made to a very, very overworked shop.

> Finally, rather than take *my* word alone, my management
> (like any competent management) would like to see if what I say
> holds true for other AS/400 shops: preferably shops similar to ours.
> IBM might have a list of shops similar to ours who use Code/400.
> That's why references from other shops are important.  If nobody
> else uses Code/400, that simply doesn't bolster my case that it's
> a great product that saves us time and effort.

Sure, I can see that. But, since this may not be available, I suggest
looking at the actual requirements for testing the product.

But, Buck, this is a significant undertaking. To start with, you will need
to get a handle on what you can do with Code/400. The guys testing will
need to have some goals defined. They will need a list of things the shop
believes are necessary for this product to succeed. Also, a list of things
that are special issues at the shop that the product will need to fit
into. (For instance, to you already use Aldon to track all your source
changes? How will this cope).

What I think would happen is that after two weeks you would see the
potential of the product but not be close to achieving that. If you really
want to get the ball rolling, have someone get some real training on the
product BEFORE the test.

> Buck Calabro

Oh, yeah, sorry if I have been rude. I'm not pissed, just in a big hurry.
I haven't been spending much time at home and I am always behind on my
email. So, I tend to rush through instead of waiting until the less
emotional words come to me. 

I apologize if this has been too much the case. You, nor anyone else here,
have done nothing to warrent me being rude.  

Chris Rehm
Mr.AS400@ibm.net

How often can you afford to be unexpectedly out of business?
Get an AS/400.
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---