Re: CODE/400

Chris,

In a message dated 98-03-04 03:04:16 EST, you write:

> Dean, let's not pretend that if IBM drops the price of Code/400 they will
>  ship as many copies as VB. Just a few moments thought might indicate to
>  you that the two markets are different size. For the product to be a
>  success and to allow for upgrades, growth, and future support, it has to
>  make a profit. If it is a money loser, they will just dump it.

Sorry if my post was unclear, I didn't mean to imply _that_ at all!  What I
meant to convey was that these shops with management's finger on the ROI
button at all times would be more likely to get Visual Basic as a trial
replacement editor at $100US before they'd get CODE/400 at $1K US.

>  Before you suggest that they will make it up by selling more hardware,
>  recall that IBM can sell hardware running NT and they don't have to take a
>  loss on software to do so. It isn't IBM that will be retooling at that
>  time.

I would never suggest such a thing!  (Although, I _would_ like to see them
sell more hardware, just on principle ;-).

>  What do Code/400 buyers get that Visual Basic buyers don't? Well, the
>  Code/400 gets a product designed specifically to work with the AS/400.
>  Isn't that where your profession is? Isn't it you who gets the benefit of
>  the increased productivity and ease of use? 

For now.  But I get more and more requests for (pick your PC development
language) skills to write C/S applications that interface to the /400
database.  IBM's market direction is taking hold, and the AS/400 is slowly
becoming the "server of choice".  What will happen to those whose "profession
is" AS/400 application development when there _are no_ applications (other
than triggers, stored procedures, and database servers) running on it?

>  > >  If companies are going to steal software, whether that be Visual Basic
or
>  > >  Code/400, then they are going to do that. If IBM drops the price on
>  > >  Code/400, it will simply mean that these companies are stealing a
cheaper
>  > >  product.
>  >   
>  > Exactly.  They can steal VB for $100US a pop, or CODE for around $900US/
> pop.
>  > Duhhh, which product would _you_ steal under the same circumstances?
Even
>  > stolen copies would mean more people using CODE, thus increasing the
>  > likelihood that the thieves would recommend it to a new employer.  
>  
>  Well, given the same choice, I wouldn't steal either one! Nor would anyone
>  else at a place where I am employed. I make my living selling software, so
>  I discourage stealing it. 

Me neither.  I used to sell software myself.  I was merely playing "devil's
advocate" on the issue.

>  By the way, why would you think that someone would prefer to steal a
>  cheaper product?

Because it was easier to talk management into buying it in the first place.

>  > Again, I disagree.  If I weren't shackled to the AS/Set CASE tool by
SSA's
>  > BPCS product, I'd buy CODE/400 in a nano-(perhaps ohno?) second.  Most
AS/
> 400
>  > shops that actually _have_ a development staff _WANT_ to do something
new.
>  > Unfortunately, their peers (met at LUGs) are using VB or PowerBuilder --
_NOT_
>  > CODE/400.
>  
>  Well, I'd have to say the preponderance of evidence shows you are wrong.
>  While these people might see VB or PowerBuilder, they don't do anything.
>  If you are writing RPG code on an AS/400, for the last several years
>  Code/400 has been a great tool to enhance that. 

And what "evidence" would this be?  The only "preponderance" I've seen so far
is people unable to talk their management into purchasing CODE/400.

>  What you are telling me is that you think programmers and managers who are
>  cannot find enough staff members and who have a backlog of programs
>  needing coding decided not to pay $800 because there are cheaper packages
>  that don't let them develop RPG for an AS/400. 

I don't recall either saying _or_ implying that, but let's go with it.  My
current primary client has averaged 6 months/employee trying to find qualified
AS/400 personnel (this _AFTER_ dropping the requirements for knowing either
BPCS _or_ the AS/Set CASE tool).  They can have a VB "guru-level" employee in-
house tomorrow -- probably for less money than they pay their _junior_ AS/400
folks.  What I'm trying to say is that all the productivity gains in the
_world_ will not help if you cannot find qualified personnel.  Yes, AS/400
folks can pick up CODE quickly.  Where do you find them?  A VB'er probably
won't pick up CODE quickly, but he/she is certainly easier to come by than
someone that can.  If the current developer shortage continues, I can envision
C/S projects being approved merely because there _ARE NO_ people available to
do the green screen work.  That would be a bad thing, IMO.

>  If the product cost $5000 a seat, it would be a good deal for AS/400 shops
>  anyway. 

Perhaps.  The _actual_ cost isn't the issue that I'm agruing here.  It's the
_perception_ of that cost by management.  More and more shops are managed by
non-technical folks that don't have a _CLUE_ as to the value-add of something
like CODE.  All they see is SEU="free", VB=$100US, CODE=$900US -- a no-brainer
decision for a Harvard MBA looking to minimize expenses for the sake of
minimizing them.  Throw in VB="C/S applications that _MY_ management has read
about as the flavor du jour", and you're dead in the water as far as CODE is
concerned.

>  If an MIS shop doesn't have a backlog and doesn't need to increase
>  productivity, they could buy the product and fire some of their staff.
>  Then those guys could buy a copy of VB, and sit around the house pasting
>  together apps and watching them blow up.

Application reliability _RARELY_ appears as part of an ROI analysis...

>  > If you are fortunate enough to work at a shop that works with major
packages,
>  > you are (in part) saddled with:
>  >   
>  > A.  AS/Set CASE tool -- SSA's BPCS.
>  > B.  Synon CASE tool -- MAPICS and others.
>  > C.  WorldVision CASE tool -- JD Edwards.
>  >   
>  > I'm sure that there are others (couldn't remember the package that
specified
>  > Lansa's CASE tool).  In these instances you _CANNOT_ use an editor other 
> than
>  > the one provided by the CASE tool.  Also, there is no (desirable) way to
>  > "reverse-engineer" your tool-generated code into CODE/400, unless you
plan on
>  > never taking another vendor-supplied upgrade.
>  
>  And your point here is? I could have sworn we were discussing the merit of
>  Code/400 compared to SEU. If you are already "saddled" with a tool that
>  increases productivity, then I don't think that falls into this
>  discussion. Except for, of course, indicating that AS/400 shops must be
>  forced into improving their tools. In this case, you indicate that you
>  must be forced into using a Case tool and that you resent it.

My point was that many of us would _like_ to use CODE, but cannot.  I do not
argue the merits of CODE over SEU, merely why some may appear to "protest too
much".  BTW, one of the reasons CASE has not become ubiquitous is that
productivity does _NOT_ increase much.  This is in part due to the lack of
adequate "Upper CASE" support on the AS/400, and partly due to the additional
system resources that CASE-generated programs consume.  With CASE as it stands
now, you just end up writing a _better_ program than you would have written in
the same amount of time using a 3GL language.

  > Righto, mate!
>  
>  Agreed. One of us is disappointed that lured and coerced into improving
>  productivity. If this keeps up, IBM might decide that AS/400 shops are on
>  their way out and IBM needs to find a new set of developers if they want
>  to keep the hardware shipping. 

Huh?  Missed that one...

Regards!

Dean Asmussen
Enterprise Systems Consulting, Inc.
Fuquay-Varina, NC  USA
E-Mail:  DAsmussen@aol.com

"Salmon Day (n) -- A day spent swimming upstream, yet ending up in the same
place you started."
+---
| 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
+---