RAD ups and downs

Since around 1995, the acronym RAD is used for “Rapid Application Development”.

It means a development tool or an entire development environment that allows a programmer to quickly create and incrementally change an application whose requirements satisfy the application field of the tool or environment itself.

The most famous RAD environments are Microsoft Visual Basic and Borland Delphi, but there are much more.

There are also RAD tools that may be integrated in a non-RAD environment, like Glade.

As no developer wants to take more time than necessary to build a given piece of software, and as not every kind of software development is done using RAD techniques, obviously such techniques have limitations or disadvantages that prevent their usage to develop some kinds of applications.

Let’s first examine RAD techniques limitations.

RAD techniques are component-based. Using a RAD tool means to place in a window the icons representing the needed components.

All RAD tools are component-based, but not all component-based software tools are RAD tools.

In addition to being component-based, RAD tools add “direct manipulation”, that is such tools allow the user to manage the components by using a graphical application, and seeing immediately the effects of his/her changes.

There are advantages and disadvantages both with component-based software development tools and with direct-manipulation software development tools. Let’s see them separately.

There are essentially two kinds of RAD techniques: form designers and database accessors. These techniques are combined in data-bound controls, but may be used independently.

If most part of an application is not about dialog boxes nor about database access, RAD techniques are of little use. For example, no one uses a RAD tool to build a real-time application, or a device-driver, or a system administration script, or a computer game, or a compiler, as RAD techniques are not useful for such kinds of software. For some other applications they may be of some use, because they have some forms, or make some database access, but a large part of the application has other challenges.

There may be the case that RAD components are not flexible enough. They may impose a look-and-feel different from the one desired by the developer, or an inefficient database access technique.

Of course one may search for a better alternative, but it may be hard to find the optimum component in the world; and one may develop his/her own components, but it may be hard to do, as it requires advanced programming techniques.

Component programming has much progressed along the years.

The first generation RAD tools have no custom component support.

The second generation RAD tools allow to construct custom component using a lower-level language, like Visual Basic VBX, that have to be written in C language.

The third generation RAD tools allow to construct custom component using the same language used by application programmers, but the generated libraries have to be separately installed and run up against versioning problems, like Visual Basic OCX, that could be written in Visual Basic itself but have to be installed and registered in the user computer.

The fourth generation RAD tools allow to construct custom components using the same language used by application programmers, and incorporate them inside the application (using a linker), needing no installation, like Delphi VCL or .NET UserControls.

Another trend is that while first generation components can be created only at design-time, last generation components can be optionally created also at run-time, using specific code statements.

Except for maintaining legacy software, now there is no reason to use previous generation tools.

The main issue of component-based software is that for a component vendor it is hard to provide all the feature requested by all users of the component (i.e. application programmers) and no more. It is a situation analogous to that of any software library vendor, but with some differences.

A software library vendor may provide a huge library to support really many use-cases. The size of such huge library may slow down somewhat the compilation process, then the linker includes in the generated executable only the routines and data structures actually used. Therefore a small part of a huge library does not damage the performance of the resulting application.

Instead, a component first of all shows in the property page all its members, and if such lists (properties, methods, events) are very long, they may be daunting to navigate. In addition a component is added entirely to the generated executable; and if only a small portion of it is needed, that may disproportionately increase the data size, the code size, and the time to initialize and update all the data. Actually, components are typically used for large-grained features, that however use several tens of kilobytes and take several milliseconds to process. But if there is a need for a feature using less than ten kilobytes or whose update time is less than one millisecond, a RAD component may be inappropriate.

Regarding direct-manipulation, such paradigm is quite similar to WYSIWYG word processors. For simple tasks, this kind of word processors are quite easier to use than tagged text, like troff, TeX, or SGML, and actually they experienced a boom in usage not only among consumers and isolated clerks, but also in large organizations.

The main issues with WYSIWYG word processors are:

  • Non-standard and often obscure format, that may be processed only using the word processing application itself.
  • Non-obvious status of the word processor and of the document, that often generates unexpected results (for example, for a user it is not easy to distinguish between a hard new line and a word-wrap).
  • Possible inconsistent formatting, if direct formatting is applied instead of style-sheets.

Those issues are replicated in direct-manipulation RAD tools as:

  • Non-standard and often obscure settings, that may be processed only using the RAD tools itself.
  • Non-obvious status of the RAD tool and of the application source, that often generates unexpected results (for example, for a developer it is not easy to understand the order by which the components will be processed).
  • Possible inconsistent settings, if settings are applied directly to every component instead of using a routine.

In addition, direct-manipulation RAD tools have the following issues:

  • Many components do not provide internationalization support, as the developer has to write a specific text of a specific length.
  • Many components do not provide automatic layout facilities, as the developer has to place components in specific places of the form, and a layout change requires a long and cumbersome series of manual re-alignment.
  • Many RAD tools generate source code, that calls or is called by user code. Some tools are two-way, meaning that they immediately interpret changes the developer makes to the generated code to change the properties of the tools, while one-way tools forbid or ignore such changes. Both kinds of tools have issues.
  • In case on one-way tools, the code generated by RAD tools is not source code, and so it should be kept among intermediate files, but is has to be processed by the compiler like source code, and so it should be kept among source files.
  • In case on two-way tools, the code generated by RAD tools is not source code, but it may be intermixed with code written by the developer, which is source code, and so it should be handled part as generated code and part as source code.
  • Code generated by RAD tools may not respect coding standards, and may be hard to understand by developers when debugging.
  • Code generated by RAD tools be less efficient than equivalent code written manually by a developer.
  • Many RAD tools favor mixing user interface logic with application logic and with data access logic. The resulting code is simpler in simple cases, but is more tightly coupled, and therefore less easily maintainable, as every change in requirements may force major changes all over the application.
  • Many RAD tools have smart properties that may be used as simple variables but actually access the user interface toolkit or a database when accessed. Using such properties in loops may be inefficient and hard to test and debug.
  • Many RAD tools have smart properties that generates events when changed, and an arbitrary routine may be attached to such events. For example, when a statement changes the value of a check box widget, that changes may automatically call the same routine that is called when the user checks or unchecks that widget. Such behavior cause the code to be inefficient, hard to test and debug, and sometimes it may cause infinite recursion.

As a conclusion, when it is better to use a RAD tool and when not?

It is important to notice that a project may have subprojects and that a RAD tool may be used for some subprojects and not for others.

The choice to use a RAD tool for a given (sub)project depends mainly on the following conditions:

  • The size of the (sub)project in man-months. The smaller is the (sub)project, the better is to use a RAD tool.
  • The probability that the resulting software will be actually used anyway for a long time. The likelier the (sub)project will have a short life, the better is to use a RAD tool.
  • The fact that the (sub)project involves mainly data entry or database interfacing or not. The bigger is the portion of development dedicated to data-entry form designing or to database interfacing, the better is to use a RAD tool.

In short use a RAD tool for a small (sub)project, that probably will be used only for a short time (if at all), and that has many forms with many fields; but don’t use a RAD tool for a large (sub)project, that probably will be used for a long time, and that has many features not regarding forms nor databases.

For those who cannot think of software with a short life expectancy, here are some examples of projects that have an expected usage life of less than 6 months:

  • Software to organize specific political or social events.
  • Prototypes of larger applications.
  • Experimental software (if successful, they may be used for a long time, but they are probably unsuccessful).
  • Software to migrate data from a legacy information system to a newly adopted information system.

Of course, it is hard to decide, in case a project is of average size, or probably will be used for an average time, or has some forms but also some other features.

And it is hard also in case of a project that is large but it is only a collection of forms, and so on.

As a rule of thumb, I would suggest the following rules, where, as size of the project, I mean the effort to deliver the first version to end users.

  • If a (sub)project is large more than 12 man-months and has some data-entry-intensive parts, split it to a data-entry-intensive subproject and a computation-intensive subproject, if possible. This is needed to use the best tool for each job.
  • For a (sub)project that requires less than 10 man-months, if it is data-entry-intensive or if it has an expected usage life of less than 6 months, use a RAD tool, otherwise don’t.
  • For a (sub)project that requires more than 10 man-months, don’t use a RAD tool.

About Carlo Milanesi

I am a software developer in Italy. I have develop financial, engineering and commercial software using many programming languages, mainly C, C++, Visual Basic, Java, and C#. Now I am interested in Rust and TypeScript.
This entry was posted in Uncategorized. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s