I am not sure I agree with this. Were we restarting today, the availability of less expensive hardware in the System i arena and the need for IBM to find, and perhaps fund, a software solution on i, would lead me to conclude that a “pure” ILE RPG solution could make sense. Certainly the past four years of experience would lead me that direction as well.

The cross platform approach was decided before Nathan was hired and was based on several factors that were debated at length. Had Nathan been part of the mix early on, we may have arrived at a different conclusion and a different strategy. Hard to say at this juncture.

That doesn’t mean that I think a cross-platform approach isn’t valid. It is just that in this case, and because of what we were trying to accomplish, an ILE RPG approach would have been less risky overall and (hindsight is 20/20) a faster way to get where we wanted to be. It might have limited future sales but the lower hardware costs on i today would have ameliorated that. Most importantly, the existing customers on i would have gotten their new code quicker.

I’d definitely do things differently. The tools are better than they were when we reviewed options in 2001 and the System i a very different animal. The mistake would be to do this the *same* all over again. That ain’t gonna happen.

On the pro side, we did more than due diligence in proving both J2EE and ILE development options and gained a lot of knowledge from it. Indeed we spent nearly 5 years testing and proving both. Unfortunately most of that knowledge appears to be lost as the principals were forced pursue different paths as of late.

On the con side, it established an on-going conflict of interest between the J2EE camp and the ILE camp specifically, and other camps generally. Detailed designs about our respective architectures under a different setting might have been protected as trade secrets, but in a single-company setting forced to share with the competition, so to speak.

The ILE team had a jump-start with my Web development framework, while the J2EE team struggled with alternatives, so the J2EE team was playing catch-up from day one and spending a lot of extra time reinventing the wheel, as they say. One of the big problems for the J2EE team was that their program models were patterned after the ILE models (a management decision) so the screens were quite similar, but the performance between the two was about 10 to 1 in ILE’s favor - which the customers noticed, and they also didn’t like the extra work to set up and maintain the J2EE runtime environment (Tomcat or Websphere).

Notwithstanding the success of the ILE prototypes and applications, three Vice Presidents who all favored the J2EE track felt they needed to ride herd over me which was overly constraining.

There was a lot of time spent on politics and positioning that could have been spent on development.

As resources for funding new development became constrained over time there appeared to be less communication and cooperation between the development teams and key people appeared to become more distanced and self-serving.

Finally the company imploded and splintered, leaving most of the original principals pursuing separate paths, while a few key people try to rebuild from what’s left.

Something to note, however, and I think this is important: You *really* need to have a development plan and then follow it. In this case, we started with a cross platform approach and then added an ILE, System i centric framework (a good one, IMHO, see: http://www.relational-data.com ) that was basically at cross purposes with the original stated direction of development. This wasn’t a bad thing, it just was confusing to everyone on the original development staff (and it was a reflection of what was to come, management-wise). Had our original stated goal been to develop a System i centric solution rather than a cross-platform solution then no acrimony would have ensued. However, the solution, which resulted in this two pronged approach, was a disaster, for all of the reasons I stated before.

Nathan’s prologue is right on. The company is a very different entity today. And, chasing the “holy framework grail”, they are investigating PHP. The problem with this approach is that the framework isn’t the problem. The management of company is. Had company management stayed out of the control of development and the Java OR the ILE solution been adopted (not both) the company would be in a much better place today.

Another thing learned is that in developing a successful software company, technology isn’t the issue, management usually is.

Pete’s description of the “two pronged approach” underplayed the struggle between those who favored cross-platform development vs. those who favored a System i centric solution running under the native virtual machine, where Pete and I were the strongest voices in the respective opposing and competing camps.

Perhaps predictably, our customer base and the company line of credit were unable to sustain competing development tracks and we eventually splintered. By May 2007, five of the seven members of the original management team had resigned (including Pete) and about half of the developers were laid off (including all the Java developers).

Having all the Java developers gone was ironic because the cross-platform approach was favored by the majority of management, though somewhat out of sync with the customer base. We also had a small .Net based development team working on another product line, but it was spun-off and sold to another company.

Finally it appeared that the company was committed to shifting in whole to a System i centric approach using my ILE frameworks and tools but at the same time the majority shareholder began pressuring me to change the terms of our partnership and license agreements to be more favorable to him, which ultimately forced me to withdraw from the company too.

Today the company has substantial software assets, but most of the original developers are off doing other things, leaving a small number of people supporting the Web-based product line while the company reassesses it’s development options. The last word I heard was that they were going with PHP, while I continue along the ILE track.

I like RPG but when I see the argument that RPG is as good or better language for business as Java I know the person making the argument does not know Java and OO. Abstraction, polymorphism, encapsulation, etc are all tailor made for business logic. Reuse of RPG components in a web application is an interesting challenge but a Java solution using Spring and Hibernate should only half as much code as an RPG solution.

Thanks for the comment. I equate programmers getting enmeshed with UI design and endlessly tweaking UI with the elimination of secretarial and administrative help and having managers and staff do their own correspondence and other minutia. Sure, you are capable of doing it, but is it really an efficient use of the resource?

Agile development techniques can be helpful because it can focus you on the essential function and keep you from getting sidetracked. In our case, the business logic was encapsulated by the RPG put the application in RPG III did not have a modular design that allowed use to leverage it. We simply re-wrote the business logic in Java and RPG. However, had we focused only on that, as you illustrated, we would have had a much more complete solution much earlier.

I worked with an experienced agile architect last year and he used Peter Coad’s Feature Driven Development (FDD) technique to lead the project members in focusing on the business logic. For two months we developed business logic with minimal UI (just enough to accept input and show the results to the client) and no connection to the database. We later added persistence and more robust UI features including Ajax.

I realized later that the focus on pure business logic kept us from creating screens and tables that we would later have to modify. In that way we avoided project churn. The cost of churn, re-doing whats already been done, can stop a project’s forward momentum completely. We were able to do things right the first time by delaying activities until sufficient knowledge existed to do it right.

My project was new development so FDD worked well in that arena. In your attempt to refactor an existing app leaving business logic in the RPG, I would want to proceed as though I was developing in a pure FDD model, i.e., have the client identify a few important, core features for each iteration and then work to deliver them.