There are different levels of skill and different levels of software complexity.
In the film industry there is Avid, Adobe Premiere, and Apple Final Cut Pro.
There is also Premiere Elements, and Apple iMovie, and if you're into pain,
Avid's Pinnacle Studio.
The same conversations go on in that world when someone tries to do something in
iMovie that "can't be done" and "should be done" in Final Cut Pro or Premiere.
Certainly a shop of professional programmers has to make a decision on workflow.
They have to make decisions on standards. They have to choose professional tools
for their jobs, in order to get their jobs done in an expected timeframe.
A one-person shop (consultant, contractor, etc.) sets their own standards. They
often do set a professional-style workflow, but then they also often use
whatever it takes to get the job down quickly.
The only time it causes problems is in the professional shop (in our world, an
end-user System i shop or a software house) when an individual uses a
non-standard tool to implement something other than a one-off task.
If you're supposed to use RPG IV to update database files in your shop, use RPG
IV. The people behind you will know how to change it. If your shop uses SQL to
batch updates, use SQL for batch updates.
It is when the rogue programmer _decides on their own_ to use something
different that they cause problems. Remember, in this context individuality is
not appropriate. Which is why so many people like working on their own.
So if an RPG Coder in Shop A uses the shop standard of RPG IV to update a batch
of records, that means that person did a great job. If an RPG Coder in Shop B
used the shop standard of SQL to update a batch of records, it means they also
did a great job.
I know SQL pretty well, I almost always use it for one-off updates and fixes. I
almost never use it in production code. Why? Two reasons: (1) I have to stop and
think how to code complex SQL statements (I don't have to do that with RPG IV)
and (2) Most of the people that update my code after I'm gone won't know SQL and
it actually causes them problems. But in 99.9% of the cases, they do know RPG
IV.
Does that mean my workflow is better than someone who says they would use SQL in
that situation and never RPG IV? Absolutely not!
The problem with our industry or rather our marketplace is that we have way too
many one- and two-person consultants speaking on behave of people that have no
right to speak for. If you constantly tell System i shops that "you need to use
tool X, Y, or Z or your obsolete" you give their employer the ammunition they
need to start listening to the .Net faithful.
What needs to be done is not say "Use X or your dog will die" what needs to be
said is that you need to make yourself valuable to your organization. Make
yourself part of a solution. Make your company understand that you can and want
to do this or that application with the System i; it can do it.
May IBM's System i slogan should be "I want i", but "i can do iT".
-Bob Cozzi
www.i5PodCast.com
Ask your manager to watch i5 TV
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [
mailto:rpg400-l-bounces@xxxxxxxxxxxx] On
Behalf Of rob@xxxxxxxxx
Sent: Thursday, April 26, 2007 8:18 AM
To: RPG programming on the AS400 / iSeries
Subject: RE: Chalk one up for "The Cycle"
Now wait a second.
<snip>
So James saves a bit a time using the cycle, which will be wasted 10 fold
by anybody coming in after
him trying to follow the implicit logic in the cycle program.
</snip>
Many have used the same argument against newer stuff. I don't buy it.
Would I have used SQL in this case? Yes.
Would I use the cycle when appropriate? Yes.
Would it confuse others? Yes. I once delayed none other than Jon Paris
with a bit of code that used a primary file.
If the cycle was brand new instead of 25+ years old would some people be
jumping on that bandwagon? Maybe.
Rob Berendt
midrange.com
