One of my favorite sayings is, "When the only tool you have is a hammer, you tend to treat all of your problems like nails." I don't know who to credit the saying to, but have found it to be very accurate for software application development. Software developers are more apt to use tools that are familiar rather than experiment with tools that might make the job easier and/or more efficient. The purpose of this article is to compare and contrast application development tools, and discuss which software projects are best addressed by Oracle Developer.
My first experience to software development came in the late 1970s with the BASIC programming language. It was useful for teaching simple programming constructs, but was difficult to do any real work. Later, while attending high school in Silicon Valley, I had the chance to take a Pascal programming class. One of my assignments involved creating a simple database program using records. During my senior year, my dad got me a job at Oracle Corporation, and I was immersed in the database world.
While at Oracle, I worked in the telesales department and had the pleasure of learning the earliest versions of Oracle Developer. There was a huge difference in creating running applications. While it took me a good three months to write a simple database application using Pascal, it only took an hour using Oracle's development tools. As obvious as that example may seem, I continually see companies or departments try to do things the hard way.
In the same way that development tools have evolved over the years, so has the method of deploying applications. My first applications were written using a Digital Equipment Corporation VT100 terminal talking to a host computer over a serial port connection. There was no such thing as a graphical user interface (GUI), and a PC resembled something that looked like three refrigerators and two dishwashers stacked next to each other. Times have changed since then. Most people wouldn't even think of using a computer without a GUI, and PCs now fit in the palm of your hand. While a dumb terminal connected to a server is still a valid method of application deployment, there are several others, such as client/server and the Web, which are better-suited for given environments.
Criteria for Oracle Developer Applications
Oracle Developer is not the tool to use for all software development projects. One of the demos Oracle shipped with the first GUI release of Forms 4.5 (one of the predecessors to Oracle Developer) was a chess game. While this showed what was possible, another development tool would have been better suited for the task. Therefore, it is important to qualify what types of applications are best created using Oracle Developer. Oracle Developer is geared toward applications that do the following:
- Rely on the Oracle database
- Use a large number of forms and reports
- Span multiple platforms (that is, Windows and Unix)
- Use multiple deployment methods
Oracle Developer should be the first tool evaluated for any application that relies on the Oracle database. While another tool may turn out to be a better choice, Oracle Developer should be considered. The other three criteria act as a further reinforcement that Oracle Developer is the right choice for the application.
Applications that Rely on the Oracle Database
When we talk about applications that rely on the Oracle database, we mean those that use Oracle extensively. While Oracle Developer can be used with other ODBC databases, it is not recommended as the primary development tool, regardless of what the Oracle documentation says. Oracle Developer is meant to be used with an Oracle database, and has some built-in features that dramatically cut down development time.
When Microsoft's Visual Basic first gained popularity back in the early 1990s, a lot of developers decided it would make a great database application development tool. Several third-party companies even came out with products to make database connections easier. However, when it came time to develop anything but the simplest single table for, the complexity of the application code became hideous. A simple master-detail form required a lot of extra coding (and therefore a lot of testing) to make sure the code was correct.
Oracle Developer was built from the beginning to interact seamlessly with the Oracle database. Master-detail forms are created using as few steps as possible. This results in fairly complex application elements being developed quickly and efficiently.
Applications that Use a Large Number of Forms and Reports
Oracle Developer is an efficient tool for developing database applications that use a large number of forms and reports. Forms are best described as user-modifiable data screens. Forms are generally used to modify or add data to the database, while reports are used to simply display the data. If you are building an application that uses one or two forms and no reports, the cost to acquire Oracle Developer may not offset the efficiency derived from the development tool. However, if you have an application that utilizes hundreds of forms and/or reports, the time savings alone will justify the cost of the tool as well as any learning curve required to use it.
A note should be made about taking the entire scope of the application into account before deciding for or against Oracle Developer. I have seen many projects start out small with only a few forms and reports, only to have it explode when the users discover what is possible. This could mean the application will need to get rewritten, and sometimes that is the best solution. However, if there is a possibility that the application will grow well beyond the original scope, you may want to consider Oracle Developer from the beginning.
Applications that Span Multiple Platforms
Oracle was one of the first software companies to embrace cross-platform products. Back in 1986, I worked at Oracle, modifying their Leads tracking system. I would do all of the development and testing on my PC and then upload the finished application to a VAX 11/750 for the telesales department to use. Even if Microsoft Windows seems to be the platform of choice for most users, Oracle has continued to support other application environments as well. This support extends to both Unix dumb and X-terminals. While many developers will not need this added benefit, those that do will need it badly.
Applications that Use Multiple Deployment Methods
The Web has dramatically changed the computing world. During the past 20 years, we have seen the computing environment move from centralized mainframes and minis to client/server and now to the Web. Centralized mainframes and minis had the advantage of being centrally administered. Then came client/server, in which everyone had a nice graphical environment that made applications much more user-friendly. The Web combines the best of those with the added benefit of platform agnosticism. Applications no longer need to be copied to each individual client machine each time a bug is fixed. This has a tremendous savings in application-maintenance costs.
While the Web is definitely turning into the deployment method of choice, there are still many environments that rely on directly connected dumb terminals or the client/server deployment method. Factory floors with applications that don't require a complex GUI are prime examples of situations in which a cost-saving dumb terminal is a better solution than using a loaded PC running a browser. While the case can be made for using a network computer, we have yet to see the costs match those of a good old fashion dumb terminal. That, coupled with the fact that there is often no room for the mouse, leads me to believe that the dumb terminal is not going to completely die any time soon.
There is also the case to be made for continuing use of the client/server model. Web connections are generally stateless, so it is difficult to determine when a transaction begins and when it ends. For this reason, the client/server model still has merit and is found in use.
One of the advantages of Oracle Developer is that the same application can be deployed in all these environments. If you know you will be deploying the application on a dumb terminal, you will not be able to use some of the nifty graphical elements such as pull-down list items or event triggers caused by mouse actions. However, that is easily taken into account at the beginning. Otherwise, no coding changes are required to deploy the application in the various environments. I find this particularly useful when I develop the application in client/server mode and then deploy using the Web.