Re: ServicePrograms VS normal Programs

Hi Carel,

> Starting to use ILE concepts in an existing application is asking
> programmers to reinvent the wheel. They have to spend time again in
> rewriting, redesigning their applications with a ROI of $0.00.

There's an ROI to learning ILE programming.  IT comes from programs with
increased functionality that take less time to develop.

Subprocedures, service programs, and ILE concepts have improved my
productivity as a programmer by 40%.  That's a pretty significant value!


> You may blame the programmer, but the decision to make the revamp of the
> programmes is made by the management (negative perception? Perhaps.)

I was talking about two different things.

One is writing modular code -- this can be done when you add functionality
to an existing application.  In fact, by modularizing the changes, you can
often make them faster because you don't have to re-write the code in
every program that needs to be changed.  It also speeds up future changes
of the same type, because you now only have one place to change the code.

For example, I have an inventory application.  Each program that can add
things to inventory was originally written with routines that search the
warehouse for an open "slot", then load that slot with data.  Depending on
the type of product being slotted, different areas have to be used (For
example, frozen sausages are stored in a differnt area than refrigerated
sausages.)  Each program in the system that added items to inventory had
it's own routines to do this.

This lead to a lot of inconsistencies in the system, but we eventually
worked all of those bugs out -- took months.

One day the warehouse management decided that a new way of slotting items
was needed.  All of these programs (we have about 20 of them) would need
to be changed to use this new slotting system.

I wrote a service program with a single routine for slotting.  I tested it
in a test environment, and then modified all of the existing programs to
call that service program.  This took about 1/4 the time of re-writing
each individual program, it had fewer bugs because there was only one
piece of code to test/debug instead of many.  It saved me a lot of time.

Now, when I want to change it or add functionality to it, I can do so
easily -- all the changes go in one place.  This leads to a system that
from the user's perspectives is better.  They can request changes and get
them right away, instead of getting answers like "it's not worth the time
and cost to change that!"

The other thing that I was talking about when I referenced modernization
is changing to a more modern user interface.

If you look at a 5250 terminal, you're looking at 1970's technology. IF
you look at the way a user perceives programs written with a 5250
interface, you quickly see that they feel like they're studying dinosaurs.
Now, on this point, I certainly agree that it'll be management's decision
to use a GUI interface instead of a 5250 interface.  But management needs
to understand that WE CAN DO IT with an RPG backend!

They tend to think of iSeries as the old reliable green screen thing, and
Windows as the colorful, powerful, flexible user-friendly system.  They
need to know that we can create web-interfaces that are very nice and GUI
for our iSeries programs.

But that never happens because the programmers don't want to learn how to
do that...  they want to keep using the same green screen systems they've
always used. They don't understand that this is killing the platform, and
that they will be replaced by Windows sooner or later if they go this
route.


> Another good reason is the old die-hard shop standards (programmers had
> to stick to), that will never change.

Functionality, user friendliness, and productivity should never take a
back seat to shop standards.  Standards are a means of accomplishing easy
maintainance -- they should never be used as an excuse to make it more
difficult to maintain programs.

> And users are not that interested in the technically advanced (?)
> solution the programme has been written; they are interested in
> functionality, easy of use and related price on value.

It doesn't have to be technically advanced to be modernized. Granted, I
like to get technical.  I enjoy twiddling bits on and off and working
programming that some might call "systems" programming.

But, you don't have to do that to take advantage of modern techniques like
service programs, MVC or web-enabling.

>
> This is my post mortem on this dead horse, valued at 2 Euro cents, the
> maximum ROI.
>

I'm also very tired of arguing here.  We're not all going to agree.  All I
ask is that the people who read these forums stop and think about it.