You don’t have to be Chuck Yeager to Break the RAD Barrier

On October 14th, 1947, US Air Force Captain Chuck Yeager climbed into the experimental Bell X-1 rocket plane and accomplished something that many predicted was impossible. Flying at an altitude of 45,000 ft, Yeager throttled up and pushed his aircraft through the sound barrier, ending speculation that the sound barrier was a wall in the sky that no aircraft could pass through.

You may ask what all of that has to do with rapid application development (RAD) and the challenges faced by the builders of applications today. Well, there is a direct correlation – today, most developers are faced with a barrier of their own, and something I refer to as the RAD barrier. The RAD barrier can be summed up as the point when you can no longer develop an application because of the limits posed by the development platform.

This is an all too common problem, one that amounts to a development brick wall, where you can use a RAD product to build some 80 to 90 percent of an application, only to have things comes to a screeching halt due to the lack of support for some must-have capability. It is that very issue that has kept hard-core developers in the realm of hand coding and building procedures manually.

Take for example a quick and easy RAD tool such as FileMaker, a product that allows you to build forms that drive a proprietary database and create some basic applications very quickly. However, once you try to move beyond the basics, say to create complex calculations and analytical capabilities for real time display, you find that the included functions and expressions leave a lot to be desired.

Other examples abound – especially with many of the web app development tools that use Eclipse as an IDE (Integrated Development Environment). With Eclipse, any time you want to do something beyond the ordinary, you wind up loading in new modules and/or frameworks to address customization needs. Over time, you become awash in canned subroutines, objects, modules, and so forth, again seeing that infamous brick wall on the development horizon.

One has to wonder if the RAD barrier is an inevitability. Will every IDE/RAD solution ultimately encounter a development brick wall?

Luckily, the answer is no – there are ways to break the RAD barrier, and just like Chuck Yeager and the Sound Barrier, it all comes down to the tool you are piloting. The key to overcoming that brick wall lies in the flexibility of the development environment to support hand-written code. For example, Alpha Five offers many events where you can insert hand-coded procedures, all from within the RAD environment. It is that unified development capability that allows you to overcome RAD barriers.

With Alpha Five, if you encounter a situation where a process needs to take place at a certain juncture, whether it is during forms processing, reporting, or event handling, you can hook in hand written code without disrupting the RAD environment. It's a solution that delivers the best of both worlds – RAD for speed in creating the routine, and hand coding for the exceptions to the norm.