Hi Paul,
I agree that the work-with/record-edit combo is the most useful design pattern for database maintenance applications. I think RPG is remarkably productive and arguably the best language for DB I/O and business logic for that type of application, but that we need to move beyond DDS for the user interface.
Productivity in this case is based less on language attributes, but more on program & screen templates that developers may come up with to pattern applications after, and whether they use an application generator or write code by hand. Some shops use templates and generators licensed from vendors.
To maintain one table, I normally write one RPG module for screen I/O, one module for business rules & DB I/O, and one module for flow-control logic. I normally use HTML templates to define UI elements, and JavaScript to make it more interactive.
When I began writing green-screen interfaces, it probably took me about 6 months to settle on DDS & RPG templates that appealed to me. After that, we used PDM to copy DDS and RPG members, and edit the code by hand for specific file/record/field names, and logic.
That copy/edit process may have taken 2-6 hours for a basic maintenance application (one DB table) - a bit more labor intensive than using an application generator, but we used that approach to write perhaps a couple hundred applications. The time requirement would increase as more files were added; more applications linked together.
When I began writing browser interfaces, it took me quite a few years to settle on HTML/RPG/CSS/JavaScript templates that really appealed to me. It was an iterative process - building a lot of ILE & JavaScript framework code in the interim.
Then I developed an automated process to generate a basic inquiry/maintenance application, perhaps similar to what Rory is doing with his product, and what you've done with yours. Code generation takes a matter of seconds, but there are still some definition steps that require some decisions that may take some think time, and may vary from application to application.
It seems to me that application generators save a few hours of work on a basic maintenance application (one DB table), but their real value is in the design of the templates and other elements that they use for input, and rely on for framework utility, which may take years to develop. It seems that quite a few shops may be in a transition period now - supporting existing applications and databases while modernizing their interfaces.
Application generators add a WOW factor for some people - makes the process look easy. But adding functionality beyond the scope of one's templates may take additional days.
Functional analysis, requirements definition, business rules (beyond basic validation), database design, and innovation still seem to take as much time as ever, and for me - often takes much longer than writing code. I don't know what we can do to replace/speed-up the human brain ;-)
-Nathan.
----- Original Message ----
From: Paul Holm <pholm@xxxxxxxxxxxxxxxxx>
To: rpg400-l@xxxxxxxxxxxx
Sent: Friday, August 14, 2009 12:55:38 PM
Subject: RPG Productivity Versus Other Approaches
Hello,
We are working on a white paper which will compare RPG programming
productivity flexibility with other approaches for i5 application
development. I would be interested in feedback/insight on the following.
The #1 most used and needed programming task is development of a âWORK
WITHâ screen. This typically in RPG is a subfile with a position to
type prompt. You typically can input a search parameter(s) and get a
list of records to work with. They are used everywhere and examples
include: work with orders, work with products, work with employees,
work with customers, etc.
Once you have a list of records then #2 most required task is file
maintenance. (Edit, insert, delete one of the records in your list. )
Roughly how long does it take in RPG to create a new âWORK WITHâ and
Data maintenance application from your experience?
Thanks, Paul Holm
midrange.com
