Re: CODE/400 -- MIDRANGE-L

** Reply to note from Buck Calabro <mcalabro@commsoft.net> Thu, 26 Feb 1998 
10:22:21 -0500

> 4. What's the ROI?
>           (<making numbers up> We can add 1 man-day per week.  At say $100
>            per hour x 8 hours, that's 800 dollars savings a week x 100
>            programmers=80,000 dollars a week.  It pays for itself in one week,
>            and is gravy after that.)

If you are paying a $100 an hour for programming time then I'd say your
madeup numbers were pretty strong/

> 5. What's the learning curve?
>           (<making more numbers up> You're a novice until noon, and savings 
>start
>            by the end of the first day.)

I disagree here. Learning the editor is easy and productive right away, but
you need to take into account set up time and getting familiar with a new
way of handling things. For one thing, there are so many features with
Code/400 that it takes a long time to just find them all! The good news is
that you don't lose productivity while you learn, although some things will
take a little longer you will make up for it with LPEX (the editor). 

I think that it will take a little time to get to know the debugger as
well. If you have a mentor, I would say two weeks is a good spin up time.
The mentor will set up the Code/400 objects and get things rolling with
development. If each person has to fumble through that process it could be
a while. It's easy to install the product, but then the projects need to be
created and someone there must do this with your work style in mind.

> 6. Where did you get these numbers?
>           (I heard about them on this cool listserv I subscribe to.)
> 7. How many other shops in the area are using it?
>           (Ummm....)

This is the #1 question stopping new tech on AS/400s. Certainly it is valid
to want to know if there is someone you can talk to who is using this
product. That shouldn't be the critical factor, though.

> 8. Why not?
>           (They're not as forward thinking as we are!)

(for the same reason we are about to reject it!)

> 9. There must be a reason nobody seems to use it.  We doubt those savings 
>     numbers because *we* can do all that funky stuff with SEU:

No, we can't. It is fine to doubt the savings. We are being wise to not
jump in head first and see how much impact there is. 

However, boss, if these numbers are even half right implementing this tool
will be like adding 10% to our staff. 

So, let's have a look at the tool for ourself. Why don't we pick a couple
of guys, maybe one senior and one junior programmer, and give them the task
of testing the product under our work conditions. Let them spend 60 days
using the tool. If it is a wash out, we should know long before the 60 day
mark. On the other hand, if it isn't a wash out, we could be looking at a
pretty decent productivity increase department wide.

If the product doesn't wash out, our two experienced users can mentor
starting the rest of us up on this one workgroup at a time. 


>  - Multiple windows (one in the current C spec area, one in the I or D specs,
> one in my subroutines, etc. etc.) - move from one to another simply - even 
>view
> the data definitions while editing the calcs.
>           Multiple sessions... cut and paste.

Limited to the size of your screen, awkward. 

>   
>  - Use bookmarks in source to quickly move from place to place
>           Line numbers

How many line numbers can you keep in memory at one time while trying to
concentrate on writing this damn routine.

>   
>  - Colour coded display so that you can tell fields apart even when they touch
>           RPG is column oriented... prompt if you're confused

Prompt! When I am browsing a source to see how it behaves? How many times
have I looked over and over in a source only to realize on the umpteenth
check that the line at the beginning of that routine is commented out?!

>  - A Tab key that knows where the fields are!
>           ALT-Right arrow works fine

Not when I am writing a new line of code. As an example, when I am loading
the fields for the klist I just defined, I don't want to prompt and force
the window to scroll right before I get the last two fields loaded.

>  - A help key that shows the relevant portion of the manual
>          Open a window on the manual if you need it

Sure, I will. But that doesn't at all compare to the value of a help search
that will pull up the _relevant_ part of the manual while I am in _working_
mode.

>  - View only lines that reference a specific field
>          F16=Find

Yes, this is almost as useful. Almost as easy to work with, and now that I
have worked with SEU for a millenium I am really handy with it.

>   
>  - Completely verify a program (i.e. a full compiler type check, not just
> syntax) in seconds _before_ wasting time submitting (and waiting for) a batch
> compile just to find that you mis-spelled a field name!!
>           We're going to have to compile it on the /400 to test it anyway

How many times? Aren't you tired of the performance bottlenecks? Do you
have any idea how much you pay in salaries for people waiting for their
compiles to come off the queue? 

>   
>  - find errors in the source simply by clicking on the error line
>           F15, option 2, *ERR, find

Oh, yeah, that is just as fast as, click on error and have cursor
positioned on that line (while error is displayed in another window).

>   
>  - full point and click interactive debugger with ability to watch any number
> of variables, etc. etc.
>           Sounds like IDSB

Yup, like Lexus is a car, and that sounds like Ford.

> 10. What about editing code out at client sites.  Wouldn't you have to use
>       SEU out there?
>           (Well, yes)

Yup, it's too bad we can't see this performance boost at the client sites.
Well, wait a minute, if we discover that this product really does work,
maybe we can recommend it to our clients. After all, which of them wouldn't
want us to be more productive?

And when you consider that they need only pay for the AS/400 component
license, their investment wouldn't need much time to be paid back.

>   
> You get the idea.

You get the idea.

>   
> I paid for a copy of the first version of Flex/Edit myself at my last job; 
> it became worthless at my current position because of all the work I do 
> dialled out to customers.  Even locally, we're attached via TCP/IP, which 
> makes even that more work than it's worth.  Now, TCP/IP has been around 
> for a real long time now; neither Flex nor CODE work natively with it!  
> When you have to keep a DOS window open to FTP your source around, 
> the boss gets real skeptical about your "savings" numbers...

You keep treating Code/400 like it is just a text editor. Yes, LPEX is a
very, very nice editor. But Code/400 is a lot more. 

>   
> Yes, I know that Flex and CODE are releasing TCP/IP versions
> Real Soon Now, but how does that placate the boss right now?
> Or, a year ago, or two years ago?  He sees this as a reason to
> stay clear of PC based products: who knows what will break it
> in the future (he wonders?)

Well, I never noticed that installing TCP/IP broke anything in Code/400. Of
course, I still connected using SNA. After all, you can use both protocols
over the same wire. Just in case there is gear out there that is too
"broken" to communicate to your AS/400 in the protocol that has been native
to it for the last couple decades. 

> Bottom line: The boss takes your view that he needs maximum 
> value for his dollar.  He does not share our view that CODE or
> FLEX makes me more efficient.  Therefore, spending $750 per
> person for the same efficiency equates to a DROP in "bang for
> the buck."

What your boss needs is to actually evaluate the potential of the tool. Do
you guys ever hire junior programmers? Why waste all the time it takes to
get them to be as familiar with SEU as you are when in less time they can
be up to speed with Code/400.

> Buck Calabro
> Commsoft Albany, NY
 

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
+---