Changing JDE code

I'm sure the comment "..there would not be a JDElist.." was not meant at all
to be a justification for making modifications to a program. What's puzzling
is to regard it so.

And "..If mods weren't done, I wouldn't have a job.." I took this to be an
example of how much software modification services are needed.

There is some common ground. For starters, I believe Tim Lint would agree
wholeheartedly, the apparent heat of his comments notwithstanding, that
unnecessary modifications are, well, unnecessary, starting with things that
the software already does or can be made to do using applications flags, or
company-settings, AAI'S, etc. Now JDE has always been in my view the best
effort in existence to make a package "all things to all people at all times
in all places".

However, if it actually had succeeded at this goal, then--pay attention
here, folks--JDE in Denver would no longer have any need at all for
programmers! Maybe a couple, as in Colin's view, to handle software glitches
that always come up. But they still have lots of them! Gobs of them!

Colin himself has mentioned that he has...
very hard for realistic and practical changes (and also with other software
companies)? There have been times that when my "push" has been so strong
that I have been "ticked" off by my immediate superiors at "business
partners" - fine I can live with the ticking off but I have maintained my
integrity and professionalism. Of course I get a "thrill" down the track
when I have seen those self same suggestions adopted in a later cume or
release (albeit in concept rather than specific detail)."<<<<<

This is actually Colin himself making a point rather contrary to Colin's
own, the difference being that he prefers on insisting that Denver make the
changes he views as needed, rather than programming consultants. Also an
admission that there is a need sometimes for programming modifications. It
is better to have the package itself changed, with that I agree, but it is
rather grandiose to expect Denver to direct resources to a situation of
limited scope (relatively).

This raises another very relevant question. >>>Where does Denver get its
ideas for what its programmers wrote, or write?<<< They get them from the
users themselves. They are the ones with the overview of their users, but
they are also the ones who decides what programming is done and what is not.
And they base it on what the best long-term interests are for JDE, what a
surprise. Of course this includes user needs, but not necessarily every
user.

If everyone had a perfect grasp of numbers and the meaning they give to
situation, there would never be a need for graphs, for example. There are
quite a number of software developers who have stepped in and filled the
breach where there are many needs that the JDE does not or cannot fill. In
fact, JDE itself will sell many of those.

I believe in convincing a company to use "better business practices", some
of which are reflected in the JDE software, but it will never be complete.
There are a lot of different (legitimate) ways of doing things, and this is
reflected in the adaptability of JDE.

I am a programmer myself, and our JDE package has almost no changes at all,
and I insisted when they got it that they should concentrate on setting it
up in the software itself with absolute minimum modifications. The work
orders generated by sales order entry had to be handled a certain way,
however, and this was a modification. To ask that they change their
"business" methods would have actually translated into major changes in
their entire manufacturing plant. Instead of this there were two minor work
order programs added in.

Re: RE: Changing JDE code

Boy, haven't seen this much activity on one subject in a long time. Actually kind of "fun". Having posted one of the first responses to this subject awhile back, I have sat back and watched the volley of responses with quite a bit of interest. JWalker hit things right on the head for me. In my neck of the woods, you often have to do a "little bit of everything". The IT/MIS/IS group that I belong to is often saddled with both the implementation phases of things as well as modifications to programs when requested. Believe me, we don't like modifying the code (even though we KNOW we can do it) because of long term issues. But the fact is, it happens and will continue to happen. And when we can, we beg JDE to put such changes in their software in upcoming releases. We've been on the software a long time (since '87) and truly think we have had some input in the software we now see.

I have many examples of cases where long ago, someone in the company (we have never used consultants) mod'd a program to "do it this way". Years (and new versions) later, this program mod is continually reapplied to upgraded programs with no regard to "why". Now someone at the company says "how 'bout we do things this way" and lo and behold, the program modification was put in place to prevent this action in the first place. This has happened more than once. When we went to 7.3 years ago, we chose NOT to reapply some mods just to see if anyone would notice (or possibly JDE had this functionality now) and sure enough, some went away. Sadly, though, more have just creeped back in.

My point is (was I making one?), as both a programmer and "analyst", I'll do anything not to mod a program but at the same time, I don't control the company. If they want it done, I will do it (and hopefully document it well!) and move on to the next project.

Maybe we should have a "lively group discussion" on this topic at the Quest Global Conference? Maybe a BOF session if someone is able to set one up while we are there?