Re: Looking for Agile Experience -- MIDRANGE-L

Well, certainly, but that is just one way of looking at it. You can of course, easily pull all that same information statically out of any RPG data structure. And you can do it dynamically with based pointers and data structures, but it gets overly complex.

Part of the issue then becomes, is Agile a methodology or is it a set of tools and capabilities? I would argue that it is a methodology that some toolsets implement, but any methodology can be implemented in pretty much any language. Including RPG. I am disagree with you that Agile Development requires any specific tools, though I understand your point.

I have used Agile methodologies with RPG code and it works really really well - as the stakeholders feel both reassured and included.

That kind of puts me in the lightweight camp of course, and I think it is the most balanced and reasonable place to be. Note that basic precepts of Agile development do not speak to toolsets, and I would contend, dispute the validity of highly structured process oriented methodologies we learned in the 70's and 80's.

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

As you might guess, I am not a huge fan of continuous integration or of AM in particular. AM works best in languages that are self documenting and lend themselves to top down OO design and development, like Ada. In Ada projects, the top level design is often the first layer of compilable code for example.

And I also tend to agree with the idea that most modern ideas of software engineering are pretty much the distilled good practices of earlier times. Avoiding tight coupling, iterative modeling, even test driven development. All good practices developed in the 70's and 80's, not really anything new that I see.

As an aside, IBM went "down the OO rabbit hole" in the 90's (Say that out loud. :) This was clearly evidenced by the VisualAge tools - like VA Generator, VA COBOL, and so forth. All of which used a Smalltalk based interface builder that was horribly complex, difficult to understand, and slow.
Also horribly expensive to develop with at the time, VA Generator required a PC with 512MB of RAM, which cost more in 1995 than 32Gigabyte of RAM costs today. The perfect OO interface was quickly given over two the non-Smalltalk interface in products like VA-RPG, and persist in the Rational products today.

And most of what was generated by those products was plain old procedural COBOL, used to create and drive CICS transactions. (grin)

-Paul

On Oct 22, 2013, at 8:27 PM, Dan Kimmel <dkimmel@xxxxxxxxxxxxxxx> wrote:

The tools that make Agile rock demand that the tools be able to examine a piece of compiled code and pull out the names and types of variables referenced in objects and static class members as well as the symantics of parameters. Can't do that with RPG modules.

-------- Original message --------
From: Paul Raulerson <paul.raulerson@xxxxxxx>
Date: 10/22/2013 8:07 PM (GMT-06:00)
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Subject: Re: Looking for Agile Experience

HI Dan - Reflection can, in some - even most - cases, be described as self modifying code - a very old concept well understood by assembler programmers from all times. ;) In this case, I think you are referring to code examining and modifying object properties at run time.

There are two extremes in this thinking, and oddly enough, both ends of the extreme use Reflection equally well.

At one end of the scale, Assembler languages fit perfectly into this definition. In assembler you examine and modify pretty much anything at any time.

At the other end, you run into the high high level languages like Smalltalk. SmallTalk is attractive in many ways, and is certainly cable of Reflection.

RPG - speaking specifically of modern RPG - sits somewhere just to the left of center. Certainly with based pointers and data structures, it is possible to build "objects" that have embedded behavior, properties, and are cable of describing themselves. Not that in RPG it is terribly beneficial to do so, but just that you can.

So I tend to see arguments about this or that capability being required for a language to fit a particular description as being mere semantics. If acts like a duck, quacks like a duck, and leaves duck dew on your pickup truck - it's a duck.

An yes, that thinking is not well accepted by OO purists, partly because they need the labels on things to be comfortable. Nor is it all that well accepted by Assembler programs, because they scoff at labels or data types, etc. They just put the bytes where they want them.

All that to get to addressing your point about testing. You could use Rational Test Case, other tools, or simply build a custom testing framework around a RPG project before writing the code, and that easily meets the formal definition for Agile development.

But, seriously? As long as you are doing full recursive testing in a manner that will expose issues as near to immediately as possible, I think it meets (or almost meets) the spirit of the idea. YMMV on that one, as I tend to take a liberal view of this subject. Or should I say I take an Agile view on the subject? :)

-Paul

On Oct 22, 2013, at 7:34 PM, Dan Kimmel <dkimmel@xxxxxxxxxxxxxxx> wrote:

One of the tenets of agile, as I understand it, is to write the tester before you write the code. To make that really successful the tester must rely on a certain amount of reflection in the language. OO languages are reflexive by definition. RPG is in no way reflexive.

-------- Original message --------
From: Paul Raulerson <paul.raulerson@xxxxxxx>
Date: 10/22/2013 6:34 PM (GMT-06:00)
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Cc: Midrange-L Midrange-l <midrange-l@xxxxxxxxxxxx>,Rpg400 Rpg400-L <rpg400-l@xxxxxxxxxxxx>
Subject: Re: Looking for Agile Experience

In general, Agile development (assuming you mean the methodology and not a particular product) works quite well with RPGIV, whether a lot of LE features are used or not.

This is because RPG is so very very terse compared to most other languages, and yet still, at the core, a procedural language.

It --> does <--- require significant available processor power, and the stakholders have to buy into it. But turning a minor change around on a screen - green screen, GUI, or Web, in a couple of minutes makes a lot of people very happy. You have to have small programs that compile quickly and very good test data that you can also reload very quickly.

Downsides are the that programmers usually need to be above average for this method to really work best. Turnarounds of a day or two on relatively minor things are not really going to work. Same with a hard nosed certainly about what can and what can NOT change too. The customer might decide he wants to change how he does his account number or something. Have to accept that and make it happen quickly.

And, like every other methodology, get the last 10% to work and work right is still the toughest part.

Works better for small or mid-range projects I think, say up to 300 or 400 programs in an application. With RPG you can push that because some programs are going to fit on a page or two.

-Paul

On Oct 22, 2013, at 03:38 PM, Jon Paris <jon.paris@xxxxxxxxxxxxxx> wrote:

Cross-posted to Midrange-L and RPG400-L

Anyone got any experience in applying Agile techniques in an ILE + RPG environment?

Jon Paris

www.partner400.com<http://www.partner400.com>
www.SystemiDeveloper.com<http://www.SystemiDeveloper.com<http://www.SystemiDeveloper.com<http://www.SystemiDeveloper.com>>

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.