Let me warn you right off: This will not be a comparison of various application development tools. Since I don't use any in production other than my own, I am ill-equipped to compare them. Instead, I want to explore the age-old (but now more relevant than ever) question of make vs. buy and the related topic of generate vs. handcraft.

Application development tool vendors beware! This shall not be a pretty column for thee. Not only will I not wax poetic over the bells, whistles, features, and fillips of any commercial products, but I'll actually spend a fair amount of time identifying situations where no tool is the best tool. And even in those situations where tools make sense, I'll only point out the need, not the specific solution: You'll still have to battle amongst yourselves for the ever-important client dollar.

But to build or not to build, that is a question I am duly qualified to address, since I hold the distinction of not only having been the Manager of Architecture of the largest AS/400 software firm in the world, but also having single-handedly written not one, but two, of the more complex software development tools in our industry. Focus/2000 was perhaps the most successful Y2K-conversion tool written for the AS/400, while PSC/400 was the first solution to remove the interactive tax from 5250 applications and remains the only tool capable of converting entire business applications to true J2EE Web applications using a single green-screen command. I mention these not to promote them, but simply to point out that I know a fair bit about code generation.

Because this won't be a sales pitch. Those who know me know I don't waste a lot of time touting my own products. At the same time, I want to be careful to avoid even the appearance of bashing other tools. So when I discuss a specific tool, I'll mention only my own, and only to point out where such tools have their shortcomings and why you might not choose any tool, even a good one. With that being said, let's move on to the topic at hand, shall we?

Application Development in the Web World

This is really what it's all about, isn't it? I don't think most of us are in the position of having to choose between things like AS/SET and Synon anymore; if you're still creating green-screen applications, you're probably well-wedded to whatever tool you're using, even if it's no tool at all. And while a small but significant percentage of shops need some thick-client development, those shops usually have some external force that determines their development direction: A Windows shop is likely to use Visual Studio while a Linux-friendly environment will probably look more at something like Java. In any event, this article isn't designed to explore either of those architectures. Instead, I want to focus specifically on creating Web-based applications.

A few fundamental questions can help you choose the right development path.

Question 1: Skill Sets

The first question is which skills you plan to have available. This is not as simple a question as it might seem at first! For example, if you use a generation tool, it's quite possible that you'll need to debug the generated code at some point. So if your development strategy includes a tool that generates Java code, you'll need to have someone with Java skills either on staff or available for contracting. The expense of a bug that you can't fix can outweigh any money you might have saved during development.

Question 2: Training

This is a very important issue. Where do you plan to get the majority of your training? Obviously, if you plan to use nothing but technologies that you are already skilled in, then you have little to worry about. But then again, you probably aren't reading this article either! If, however, you need to incorporate a new technique, it's important that you know how you're going to learn it. The alternatives depend on the approach. For a commercial product, you usually have only the vendor, although for the more popular tools you may find online user communities or occasionally even published books.

For programmatic approaches, it depends very much on the technology. For System i–specific approaches such as RPG CGI, you're pretty much limited to the occasional technical convention (such as iSeries DevCon or COMMON) or some in-house training. Another possibility is local user groups (LUGs); if there's one in your area, you can often join for a nominal fee and then pester the board for training on topics that interest you (and I use the term "pester" with nothing but affection, since I'm on the board of Omni, the Chicago LUG). The more open technologies, such as J2EE or PHP, benefit from large online user communities and no end of published material. The problem there is not a lack of information but instead a matter of winnowing out the chaff. Ask three open-source experts a question and you'll get three "best practices."

Question 3: Technology Maturity

The next question is whether you want to use older technologies or instead travel the exciting road of the bleeding edge. Neither choice is inherently better than the other; it really depends on your business goals. For this question, a lot has to do with the questions we've already covered, such as training. The newest technologies typically have the more vibrant user communities, while the more stable techniques often have loyal but sometimes less active followings. This isn't cast in stone, though: Perl is nearly 20 years old, yet Comprehensive Perl Archive Network (CPAN) boasts over 3 GB of online information and shows no signs of slowing down.

And a large following does not necessarily equate to stability, at least in terms of whether it will be around in a few years. My favorite example is Struts: Struts has a huge community and at one time was the leading option for Java-based Web development by a wide margin, but for various reasons it is dying (not the least of which is the fact that while it's a relatively easy architecture to learn, it's not a particularly good architecture). This is just another example of why bandwagons aren't particularly good barometers of technology. You really have to take the time to understand the underlying characteristics of the various available techniques and choose the one that best fits your business. There is no silver bullet, no one-size-fits-all answer.

The funny thing is that, despite my previous comment about Struts, common sense and history both tell us that the fact that something makes it to legacy status means that there is something going for it. 5250, ISAM access, RPG: All of these technologies have stood the test of time because they work. So don't be too quick to jump to a new technology just because it's new. In fact, the best solution is likely to be one that incrementally updates your applications rather than tries to replace them.

Question 4: The Future

Are you trying to fix a short-term tactical issue or trying to lay a strategic foundation? Do you have some idea of what the future might hold in store for you? Here's a simple example: Do you plan to support handheld devices? This is an important point, because it might provide some idea as to possible UI constraints. For example, while many smaller devices support Web access, the majority have an upward limit of QVGA, or 320x200 pixels. If you choose an approach that can't generate nice screens at this resolution, then handhelds are out of the question.

Comparing the Approaches

So, given the questions above, how do the various approaches compare? Well, let's first review the make vs. buy options. As I pointed out, using a vendor product ties you to that vendor's development path. This has two potential downsides and one possibly overriding benefit. The negatives include having to rely on the vendor for education and training and being unable to take advantage of new technologies if the vendor doesn't keep up. Interestingly, the former is mitigated by more popular tools, while the latter is actually more of a problem with larger vendors than smaller ones; smaller vendors usually have more flexibility in determining their next technological direction and can be more easily guided by client requirements.

The primary positive with a generated approach is that you have a much shorter time to market; this is usually the main selling point for a commercial solution! The other positive is more subtle: A vendor may have already encountered and solved many of the issues you will face and can reduce the research and decision-making required. Note that this is not necessarily the best thing; a vendor's choices are not always the best choices for your company. And even if they are good choices today, they may not be in the future. For example, my Web-enabling product requires source code. If you use my product and someday your company merges with a company that has a package without source, you will have a technological impasse.

At the same time, the training curve can be reduced drastically for a commercial product. While this isn't necessarily the case (using some commercial products is just as complicated as handcrafting the code yourself), commercial products typically have tutorials, wizards, or other rapid-deployment techniques that help get you productive more quickly.

On the other hand, creating your own solution means that you have complete control over the development process and can use whatever technologies you want. If you use a handcrafted approach, you have virtually limitless flexibility but at the price of having to learn all the associated technologies. For example, to create simple (but industrial-strength) JavaServer Pages (JSPs), you'll need at a minimum expert HTML and CSS skills, solid J2EE knowledge (how servlets work and how they interact with JSPs), and a familiarity with the Web server of choice (WebSphere or Tomcat, for example). If you decide to go the Apache route, you'll need to understand how the Apache HTTP server and Tomcat interact and learn all of the appropriate Apache directives for things like access and authorization.

Some of these skills can be rented. Let someone do one-time code for you, and then use it in your production development. That's extremely close to buying a commercial product; if you don't understand what you bought, you're at the mercy of the contractor. Another option might be to hire someone to give you a "jump start" into a particular technology. For example, I've worked with companies that simply needed someone to present them with a framework, and they took it from there. I might teach some basic WebSphere and the method to connect a servlet to an RPG back-end, and then the company can take that knowledge and run with it.

Even if you do decide to write your own software, there is some latitude with that decision. You can handcraft everything, or you can use one of the many code-generation tools out there, such as EGL. In the latter case, the tool will generate much of your code, but you may find yourself in a precarious position: If you don't understand the underlying code, you can't debug it, but since you didn't actually purchase a commercial product, your support is likely to be limited to mailing lists or online forums. I wrote in a previous column that I had some real problems debugging code generated by WDSC's Web Services wizards. Even though I had the source to the generated code, it called some proprietary classes written by IBM that had no source.

Actually, if you think about it, many open-source products and languages lie in a very similar gray area. For example, if you were to use Jython (a cross-language environment that makes Python available on Java Virtual Machines) for development and there was a bug in the code base, would you know how to debug it? I found quite a few problems in my original use of EGL, and I think it's naïve to think that any product—commercial or non-commercial—would be free of code defects. The problem is that, especially for open-source products, you as a user have little leverage with which to even find the underlying cause of an error, much less get the authors to fix something. Before you hitch your wagon to any particular product, you should find out as much as you can about the community and especially the core group leading the charge.

I took some heat a while ago because I mentioned that the creator of Ruby on Rails, David Heinemeier Hansson (or DHH as he is known in the Rails community), was a rather opinionated individual with a somewhat extravagant personal style. However, it's important to note that since DHH is very much the ruling party behind the strategic direction of Rails, you are in effect partnering with him when you decide to use Rails as a development tool, just as you are partnering with IBM when you pick the System i as your business platform.

If you handcraft, however, you have much more control over which technologies you use and which you don't. If you use a generator, find out exactly which technologies the code relies on. The code generated by PSC/400 uses no vendor-specific extensions to the language; it relies on nothing other than the most basic JSP and Java constructs. Because of this, my code can run just as easily on WebSphere as it can on Apache and Tomcat on Windows. SQL generators also have to be carefully vetted. The differences between SQL Server and MySQL, for example, have cost many a developer lost sleep. If a generator takes advantage of specific syntax for one, the generated code may not port to the other.

Are There Any Recommendations?

At the end of the day, it comes down to a question of strategic direction vs. time to market. If you want complete control of your own destiny, there is no substitute for handcrafted code. If you need to get to market tomorrow and you don't have the requisite skills, then a tool is the only way to go.

Most people are somewhere in the middle, and that's where the tradeoffs lie. My preference is to use only a few very transparent tools, allowing me to get in and hack the generated code, if only to debug things. But remember: That's coming from a lifelong programmer. I do this because I actually like programming computers! If the computer is more a tool to get a job done, then this issue becomes less important. Instead, you should take some time to peruse the support forums for the tools you are considering (if available) or talk to other users; this will give you an idea of the quality and maturity of the product as well as its level of support.

As always, the answer depends on you and your business. But this article should give you some guidance on how to ask the right questions.

Joe Pluta is the founder and chief architect of Pluta Brothers Design, Inc. and has been extending the IBM midrange since the days of the IBM System/3. Joe uses WebSphere extensively, especially as the base for PSC/400, the only product that can move your legacy systems to the Web using simple green-screen commands. He has written several books including E-Deployment: The Fastest Path to the Web, Eclipse: Step by Step, and WDSC: Step by Step. Joe performs onsite mentoring and speaks at user groups around the country. You can reach him at This email address is being protected from spambots. You need JavaScript enabled to view it..