Rapid application development promises applications without programming. Does it deliver?
David S. Linthicum
RAD (rapid application development) tools are the microwave ovens of the programming world--they're new, they're fast, and they'll probably make a lot of people's lives easier. However, as anyone who has put aluminum foil into a microwave knows, you'll see benefits only if you use the tools properly.
When all the hype has settled, RAD tools
promise two advantages
over traditional programming. The first advantage is a shorter, more flexible development cycle, enabling you to leap directly from prototype to finished application. The second advantage is that a reasonably sophisticated end user can develop applications.
Sound too good to be true? Sometimes it is. RAD tools
often require you to write code. But if you use them properly, you can reduce many programming tasks to drag-and-drop simplicity.
RAD's History
The roots of RAD lie in the prototyping tools of yore. With such tools, developers could quickly mock up an application so the end user could see and experience it before the design was finalized. Prototypes were the ultimate design tool, because they virtually eliminated misunderstandings about an application's look, feel, and capabilities. Once the developer and end user agreed on a prototype, the developer simply created an application that looked and acted like the prototype.
But these prototyping tools usually provided only "smoke and mirrors" for the developer. Prototypes rarely became final applications. After finishing a prototype, the developer might actually build the application in a language such as COBOL or C.
If this seems wasteful, that's because it is. Developers were building the application twice. To solv
e this problem, RAD tools extend the capabilities of prototyping tools by providing developers with everything they need to build a prototype as well as turn it into a fully functional application.
It's a fairly elegant solution. Developers build applications with RAD tools primarily by designing the interface. They assemble components such as buttons, menus, data windows, and combo boxes. Developers are more concerned with what the program does than they are with how it does it. They show the application to users, get feedback, and make modifications to the application. This process continues until the user is happy.
Speed Over Design
Some traditional systems developers criticize this type of
spiral development
as a process of getting it wrong many times before getting it right once. Forgoing the design stage may cost more in the long run, they say, arguing that poorly designed applications are difficult to maintain, upgrade, and port.
The "design-on-the
-fly" method of development that RAD promotes does create applications quickly, but you then have to live with the application after deployment. Many RAD applications require a lot of fixing and redeployment cycles after delivery to get them right. This is known as the
prototyping death spiral
, and it could lead to user dissatisfaction, wasted money, and a short life span for the application.
From a design viewpoint, the key to good RAD development is to keep an eye on the big picture. When using RAD, organizations should not neglect the business objectives of the application. Developers need to design applications that take the greatest advantage of the object-oriented-like features that most tools provide, and that requires planning the application's implementation. Without careful planning, an application could fail to take advantage of reusable application components--worse, the application could become an unmaintainable mess.
Even if you save time when you're designing an applicati
on with a RAD tool, you may lose that time when you execute it or port it to another platform. RAD tools typically use interpreters and not compilers, and most interpreters execute about half as fast as compiled code. There can be a noticeable performance difference compared with a compiled language. Tools such as
Borland's Delphi
and Gupta's SQLWindows make strides by improving execution speed, but it will be some time before RAD matches the speed and performance of traditional compilers.
If you choose RAD, you could also be locking yourself into a platform. Most RAD tools don't provide much cross-platform portability. Delphi and Microsoft Visual Basic, for example, support only Windows. Some RAD tools support multiple platforms (e.g., Unify's Unify and Compuware's Uniface).
Get with the Programmer
Programming without programmers is the way some vendors sell RAD tools. The idea is that by using visual programming, anyone can assemble applications
without writing a single line of code. And if you believe that
Here's an example. IBM's VisualAge (a visual-programming tool that's based on Smalltalk) lets developers assemble an application from a palette of components--buttons, windows, menus, and so on. After placing all the necessary components on the application window, the developer links such nonvisual events as print commands to the components. When the user clicks on the print button, it invokes the connected nonvisual print event. But VisualAge, like other "no-code" visual-programming tools such as Powersoft's PowerBuilder and Visual Basic, does not let developers create all applications visually.
With the exception of the simplest applications (e.g., order-entry systems and client databases), most developers will probably have to learn to program using the underlying programming language. Applications that require low-level API calls or have special calculation or display requirements will often need good old-fashioned programming. F
or example, if an application uses real-time data or array processing, it will require extra code beyond the initial visual construction.
Still, the
time gained from using a RAD tool
can be immense. Most VisualAge programmers report the ability to create up to 80 percent of an application visually, with the last 20 percent consisting of specialized functions.
RAD and Reuse
Most RAD tools provide facilities for component reuse, but fast development often means developers don't take time to design their applications to make reuse a reality. For instance, when creating an application using PowerBuilder, developers will probably select as many components as possible from a library. They can use the components as is or modify them using PowerBuilder's inheritance features. But that's only if they have the time to browse the libraries to find the prebuilt objects.
The trick to making the most of reuse in the RAD world is to construct from the gene
ric to the specific. Build simple components first and reuse them throughout the application, making modifications as needed through inheritance. Good candidates for reuse include data windows, pop-up windows, and printer dialog boxes. Code reuse enables developers to modify an application in a single location and to have the changes propagate throughout the application, saving time in the process.
Many third parties have taken advantage of the reuse capabilities in RAD tools to build plug-in libraries. A developer can extend Visual Basic, for example, with VBXes (Visual Basic custom controls) and OCXes (OLE custom controls) from hundreds of vendors. These extensions add functions ranging from development project management to sophisticated database access, often at prices under $100. The power of VBXes and OCXes is so great that tools such as Delphi and Oracle's PowerObjects have designed in the capability to use them as well.
Reuse does not happen by accident. Developers need to put the time i
nto the initial design and properly plan to set up the application to maximize reuse. The tragedy is that most RAD projects promote development speed, not reuse. Dozens of object-oriented analysis and design methodologies and CASE tools assist developers in this process. In most RAD projects, if you think through the application before you get lost in the RAD tool, you can create an application that maximizes the use of recycled code.
Applications development managers need to encourage reuse among RAD development teams. RAD tools should include mechanisms that let developers locate and use existing objects, such as shared object browsers that provide a searchable database of objects for RAD tools that are shareable among developers.
Avoiding Bad RAD
So, is it time to trade in our RAD tools for more traditional development tools, such as COBOL and C? Or is it time for programmers to find a new line of work as RAD takes over? The answer is a loud "neither." RAD has tremend
ous powers, but it is not without its limits. Although it is an important part of the enterprise applications development process, it doesn't eliminate the need for a good understanding of business requirements, a sound design, and skillful programming.
The process of building the application with the end user provides common ground, where the developer and the end user can reach an understanding as to how the application will appear and behave. But the developer is ultimately responsible for the long-term health of the application, and not just its rapid delivery. With RAD, developers can easily overlook critical issues during development, including structure, consistency, design, maintainability, and good use of reuse mechanisms. RAD-developed applications may appear healthy on the surface, but after a short time, developers and users begin to discover their shortcomings. After an application enters production, it's extremely difficult to correct problems that are normally corrected during developmen
t.
Most IS organizations will come in contact with RAD before the end of the century. Now is the time to look beyond the hype to see what it can do for you. More important, understand what RAD can't do. For all you programmers out there, your job is safefor now.
PRODUCT INFORMATION
Delphi $495-$1999
Borland International, Inc.
Scotts Valley, CA
(800) 331-0877
fax: (408) 438-8400
Enterprise
Developer $795-$3295
Symantec
Cupertino, CA
(800) 441-7234
(408) 253-9600
fax: (408) 253-3968
Microsoft Visual
Basic $199-$495
Microsoft Corp.
Redmond, WA
(800) 426-9400
(206) 882-8080
fax: (206) 936-7329
PowerBuilder $1495-$3895
Powersoft Corp.
Concord, MA
(800) 395-3525
(508) 287-1500
fax: (508) 369-3997
PowerObjects $399-$1999
Oracle Corp.
Redwood Shores, CA
(800) 672-25
31
(415) 506-7000
fax: (415) 506-7200
SQLWindows $99-$2995
Gupta Corp.
Menlo Park, CA
(800) 876-3267
(415) 321-9500
fax: (415) 321-5471
Uniface $2500-$250,000
Compuware
Farmington Hills, MI
(800) 538-7822
(810) 737-8423
fax: (810) 737-7199
Unify $1000 and up
Unify Corp.
Sacramento, CA
(800) 248-6439
(916) 928-6400
fax: (916) 928-6406
VisualAge $495-$4995
IBM Corp.
White Plains, NY
(800) 426-2255
(914) 765-1900
RAD APPLICATIONS
STRENGTHS:
Database front ends
-- sales reporting
-- decision support
Form-driven data management
-- order processing
-- customer tracking
-- inventory control
WEAKNESSES:
Math-intensive applications
-- engineering
-- financial analysis
-- general ledg
er
Real-time applications
-- process control
-- banking transaction processing
-- portfolio management
illustration_link (36 Kbytes)
RAD isn't just a pretty face
-- there are some process differences between it and traditional programming. The main difference is that, as with object-oriented development techniques, the process is not entirely sequential. In other words, key parts of development occur simultaneously.
In traditional programming, you start at the top and work your way down sequentially, from system analysis through design and programming, to
testing, finally winding up with a product. If you have any changes, you make them at the appropriate stage of the process. These changes have a ripple effect through the rest of the process: Change the design, and you have to change the code and retest.
With RAD (rapid application development), you design and prototype the interface separately from designing and programming the rest of the system. This enables you to have two groups of engineers working in parallel and mostly independently. If you change the interface (which in traditional programming would necessitate reprogramming--possibly severely), you can simply relink it with the back-end code. It may not even require any reworking of the systems design.
screen_link (28 Kbytes)
Symantec's Enterprise Developer lets developers place business rules inside a special repository, thus saving programming time.
screen_link (56 Kbytes)
Borland's Delphi is an example of a sophisticated RAD tool allowing developers to assemble applications from prebuilt components. Delphi uses an object-oriented variant of Pascal for low-level development and provides links to most major database servers, including Oracle and Sybase.
Dav
id S. Linthicum is a technical manager with E.D.S. in Falls Church, Virginia. He's also the author of several books on software development and an associate professor of computer science at a local college. You can reach him on the Internet at
70742.3165@compuserve.com
or on BIX c/o "editors."
The End of Programming
