Last summer, I heard a System i pro brainstorming about application development in today's System i world. I forget the context, but what I remember is this thought of his: "I wonder if, for smaller development teams, they might be better off buying an application-development tool instead of trying to learn newer languages and techniques."

He was referring to tool sets that generate code as opposed to tools that essentially make hand-coding more efficient. The old-school term is CASE, for Computer-Aided Software Engineering, and although the name is generic enough to remain relevant today, I haven't heard it used in ages. Similar tools exist in the Rapid Application Development (RAD) category. This is an inclusive term as well, but it doesn't come with the negative baggage associated with older CASE tools. However, RAD does include a philosophy, depending on how rigorous you want to get, of iterative development based on prototypes. Integrated Development Environments — IDEs — comprise another tool set, this one closer to the heart of hand-coding and generally accompanied by more direct control over the formation of code.

I don't want to get bogged down in a contentious exploration of terms and labels. Instead, I'm simply talking about solutions that cost money, come with a learning curve, and require an investment in a methodology for application development. Such solutions in the System i world also tend to come in various flavors. For example, many solution providers have more than one application-development package that focuses on specific business needs, so the labels can get doubly complicated. For our purpose, I'll call them application-development solutions, or app-dev solutions for short. For a comprehensive look at System i-focused offerings in this space, check out "The Twists, Turns, and Benefits of Application Generators" in the October 2007 issue of System iNEWS (article ID 21070 at SystemiNetwork.com).

Back to the Question

In the December 2007 issue of System iNEWS, Scott Steinacher explores a similar line of thought. In "Today's Application Generators Warrant A Closer Look" (article ID 21087), he shares his experience with organizations that could get more app-dev work accomplished if they committed to a tool that would give them an application-modernization foundation, so to speak, with a key side benefit of productivity.

The original premise of the comment I remember from the summer, however, was grounded more in the idea that some System i-focused organizations employ RPG programmers who are unlikely to move forward with their skills. They're treading water in an ocean of change, and eventually they'll get tired. If they're lucky, a retirement boat will pick them up. It's more likely that they'll see a shark swim by or spot a margarita bar on the beach, each of which could force them to action to utilize more modern or mainstream programming languages and techniques to achieve a goal, which would be to enjoy the margaritas or escape from the shark.

Either way, the bobbing programmers can either invest in education to learn new skills or buy a robust, fully featured app-dev solution. There are upsides and downsides to each choice, at least two distinct schools of thought, and the nagging notion that doing nothing will lead to missed margaritas at best and dismemberment by sharks at worst.

A Foundation of Resistance

Some System i pros start from a foundation of resistance, and these folks often come from two backgrounds: those who were raised on RPG and its integration with the AS/400, and those who have a variety of programming skills, can use multiple languages, and are in a constant state of learning. All of them tend to believe that hand-coding everything is best because it creates optimized code that's easier to maintain. In addition, they don't want an app-dev solution to paint their company into a corner. They might also worry about their résumé, wondering if the use of an app-dev solution could limit their employability.

In the System i world, there's also a definitive IBM camp — programmers who use only IBM tools and solutions. If it's not from IBM, it's not even on the table. Along these same lines, some programmers and managers are hampered by budgets and sometimes attitudes — they won't purchase a solution or tool if it isn't free or bundled in from IBM.

So Many Technologies

The number of viable languages and methods you can use to achieve a desired result can become overwhelming. RPG IV, Java, JavaScript, .NET, PHP, XML, CGIDEV2, HTML, CSS, Python, Ruby, and Groovy are just some of the choices. What if a company invests in education for months on end only to discover that the solution being studied is unsuitable for its organization? How many RPG shops tried to switch to Java? How many failed? Perhaps more important, how many RPG shops heard of other shops attempting to move to Java, heard about their failures, and stopped looking at new tactics altogether?

The Seven Steps to a Lock-in Legacy

The biggest risk lies in the chance of becoming obsolete due to inaction. Here's how dormancy is shaking out in some organizations:

1. Line-of-business applications (ERP and homegrown) are run on the System i.



2. System i managers/programmers fail to upgrade their skills and/or buy third-party tools to develop GUI-based front ends and new, modern-looking applications — portals, BI, B2B, or even just specific applications, rich client or otherwise, for basic business needs.



3. Upper-management officials see a history of green-screen applications and little else coming out of the System i group.



4. Upper-management leaders believe that neither the System i nor the "i" development team is capable of operating modern GUI apps well.



5. Windows-based applications seem inexpensive enough, and the Windows side of the IT group is ready and willing to expand its level of responsibility . . . or a Windows job is contracted out.



6. At some point, the organization becomes split between the System i group and, for example, the .NET group.



7. System i professionals support and maintain legacy code while other app-dev professionals build new applications.

In these scenarios, the inaction of programmers and System i managers leads to a legacy lock-in that's hard to break. This is bad for System i enthusiasts, and it's terrible for the System i ecosystem.

Marketability

Hey, it's a cutthroat world out there. Given the amount of RPG code that exists today, the System i division at IBM could no doubt spontaneously combust, and yet many RPG experts would still be able to carve out an RPG living well into retirement, even though they might have to turn into consultants and chase gigs around the world. You can also bet that some of them would be pushed toward connectivity and SOA types of solutions. So what's the answer? Does learning to use a specific tool solution limit programmers?

No. As long as the programmers understand their core strengths, the keys that will get them jobs now and in the future, they will progress. "Their real skill is being able to equate technology with business needs," notes Greg Best, vice president of sales for Lansa. "Senior guys can solve business problems and are marketable, but it's not because they know Lansa or a tool. They know business, and they can apply technology to the problem."

Similarly, vendors know of situations in which programmers or managers used tools at one company, changed jobs and went to a new System i-based organization, and eventually helped institute the tools they had used previously.

Imagine this kind of guy. In 1998 he learns HTML and becomes an expert in hand-coding it. Using tables and frames, he grows into an awesome one-man web-page factory capable of employing a limited set of tools to build extraordinary pages that publish a lot of great business information. Then other web developers start using JavaScript, XML, and databases to create dynamic web pages. Instead of learning these new technologies — or even the tools that can automate much of the code — he digs down and says, "I'm an HTML coder. I don't do JavaScript."

Any guess as to what this guy is doing in a Web 2.0 world?

Learning Curves

Most programmers place a premium on hand-coding skills and on truly understanding what code is doing and how it achieves any given result. The problem is that only an elite few can keep up with the onslaught of technology. In addition to raw programming languages, there are application servers, databases, and whole architectural strategies that come into play.

"The big advantage [of app-dev solutions] is that in addition to providing a programming strategy, they also offer architectural methodologies," notes Don Denoncourt, a System iNEWS technical editor and consultant for CAS Severn, Inc. "Without that, picking RPG, Java, PHP, and so on, you'd have to select an architecture and a development tool set, and your shop might not have the time or expertise."

Overall, the learning curve for becoming effective with an app-dev solution will always be faster than figuring out how to do it by hand.

Duncan Kenzie, chief technology officer for BCD, cuts to the chase: "You can expect your developers, if they are experienced, to be up to speed in two weeks. If they are not so experienced, it'll take two months." The average, Kenzie says — for BCD tools at least — is one month.

Other app-dev solution providers point to similar learning curves, which still vary widely depending on the tool, a programmer's experience and interest in learning, and the complexity of the applications being built.

The Advantages

Each app-dev solution has different strengths and weaknesses depending on what a System i development group is interested in accomplishing. Some solutions create Java code, and others create RPG or PHP or a mix of CSS, JavaScript, HTML, and XML. The options vary, and the solutions themselves let developers work closely with code or mask it entirely.

"What all these tools have done is taken a lot of the very typical problems that you run across in application-development scenarios and encapsulated them at a higher level so you don't have to do repetitive grunt work," Kenzie explains.

The traditional advantage of app-dev solutions is productivity gains. Companies starting major projects often consider tools to help them complete the job faster than doing it by hand, in which case the return on investment could be calculated against the number of developers and the time it was expected to take to complete the work by hand. This is still a factor today. One example is the mrc-Productivity Series, which produces Java-based data-driven web applications without any hand-coding. Either way, aside from the underlying code decision, mrc offers an order-of-magnitude productivity improvement over hand-coding.

If a company has a development backlog and there's very little chance that it can hire more programmers to get the job done faster, buying a tool for productivity changes the game. Instead of zero applications, at least the business will have applications.

"We're talking about an order-of-magnitude productivity improvement," notes Joe Stangarone, president of mrc. "When you lower the cost of building applications by the amount of time it takes, the demand for applications goes up almost exponentially."

More demand? That's the last thing your development crew needs, right? Wrong. More demand, coupled with a sanity check to ensure that the applications drive business value, will result in a development organization that provides more benefit to the company. Of course, for people who enjoy maintaining applications all day long, app-dev solutions would freak them out.

Complexity Reducers

"A lot of programmers who learned on RPG and a platform in which they started with the database, which means they learned to do it correctly with a strong foundation and building an application on top, now find themselves in this web world where suddenly data is coming at them from different databases, and they're not dealing with one computer but with a network," Stangarone says.

"It's a whole different world, but those guys know how to build applications, and they have a choice — take a couple of years to learn Java or PHP — or do what you're really good at with something like m-Power and be able to develop things 10 times faster than someone who is doing it [by hand] with Java or PHP," he explains.

Lansa's Best points out that a key benefit of a good app-dev solution is that it insulates developers from not only the mundane and repetitive coding processes but also the underlying connectivity and new technology updates and standards.

"We try to simplify things so that we take care of the technology issues and you take care of the business-problem issues," Best says. A good app-dev solution, Best notes, can become an organization's "technology insurance."

Better Standards?

It turns out there's not a good correlation between the number of developers in an organization and the sweet spot for an efficient app-dev solution sale. Although the average number of active developers in System i-based organizations seems to be three, four, or five, app-dev solution providers in our System i world can easily have customers with only one developer . . . and others with a few dozen developers.

Anytime you have more than a few developers, an app-dev solution comes with additional benefits.

"One of the things that generated applications give you is consistency in implementing and enforcing programming standards across your organization," mrc's Stangarone notes. With hand-coding, if you have five different programmers, you'll get five slightly different implementations of the standard, he says. "With a code generator, it's going to implement the standards exactly the same each time, and you'll end up with code that's more standardized," he explains.

Unreadable Code

Those who shy away from app-dev solutions are sometimes concerned about the readability of the code. Sure, it might function, but could someone actually get into it to make changes or fix problems down the road? Also, if maintenance is feasible only through the solution itself, isn't that vendor lock-in?

Yes and no. Maintenance, no doubt, would be easier with any vendor's tool rather than without it. Most of the app-dev solution providers that have been around for at least a half-dozen years are well aware of the pushback they've gotten from prospects on this issue — customers want to be sure that their code can survive, with or without the vendor, for many years to come.

"The way we do things is to use standard RPG — keep it as open as possible — and educate our customers about how the code is generated so that they're not locked in and they retain full control," notes Alex Roytman, chief technical officer for Profound Logic Software. The company's RPGsp solution uses a wizard-driven development environment that employs RPG code to essentially drive web-focused HTML, Cascading Style Sheets, and JavaScript. At the same time, Profound Logic has a solution for customers who just want to build applications for the web as quickly as possible and want little exposure to anything new — even HTML.

The Final Fears

The last big fear that IT shops face with an ISV-based app-dev solution is that the company they're working with might go out of business or be sold. The way around that is to make sure you have all the licenses you need for your code and tools for twice as long as you can imagine needing them. Your maintenance contracts should also provide clear ways out in the event that a company is purchased or merges with another and you don't like the result. Remember, this is just business, and you can negotiate everything. If you don't like the terms, walk away. You have plenty of other reasonable solutions.

What about IBM? The company's EGL solution has been hanging around the periphery of the System i world for a couple of years now. Might an IBM solution, backed by a company too big to be bought out and that's so rich it has its own island in its second life, be fundamentally better than an ISV solution?

Not so fast. IBM might not go away, but its solutions and support sometimes do. "IBM changes direction more often than we do," notes BCD's Kenzie.

So . . .

What are the key indicators that an app-dev solution is right for your organization? Are you looking for web and rich-client applications? Do you have an application backlog? Would you like to expand your application-delivery abilities sooner rather than later? Do you want to give your developers a gradual exposure to more widely used languages and techniques? Although RPG is far from dead, do you want a solution that may enable non-RPG experts to be effective for you? Do you want the ability to move an application — gasp — to another platform?

If you answered any of these questions in the affirmative, it might be time to (re)consider an app-dev solution.

Chris Maxcer is the news editor for System iNetwork and a writer who covers business-computing issues. “Most articles,” he says, “have a beginning, a middle, and an end — a structure that has been around for centuries. That’s why there are all these automated article-generating tools available online. I’ve written all my ‘Maxed Out’ blog posts using an article generator and have used a generator for this industry report, too. About that metaphor with the margaritas and the sharks — I contract out all metaphors to writing services overseas.”* You can reach Chris at cmaxcer@SystemiNetwork.com.

*Note from the Editors: Chris is just kidding. His editors are responsible for all insight, direct quotes, and most definitely, all metaphors!