RADs (Rapid Application Development) came about over thirty years ago, as an answer for a world of technology in full evolution for which cascading methodology proved too burdensome in the search for agility. A promise of the possibility to build applications in an interactive manner boosted these tools that changed the ways –known so far– in which solutions were built.

With time, many of the RAD players in the market became obsolete or went astray, with only a few survivors –and, luckily, with GeneXus among them.

Nowadays it is quite normal for software construction processes to include developers who are xperts in different and new technologies that have grown apart from the vision of the business, as well as technicians specialized in functional areas who become disconnected from technology. There are usually generation gaps between these two actors, while communications has turned into an issue of its own.

This approach does not seem to be the ideal one, and that is why RADs have acquired significance again as a way towards a democratic construction of applications.

This is so much so, that, according to Gartner, by 2020, 50% of all applications will be built with this kind of tools.Today it is common to find companies that use RAD for defining solutions, in full or in part, as is the case of , for example, Mobile.

Of course, there are several reasons that have been preparing the scenario for this, with a renewed space for the RAD concept.

On one hand, the increasing importance of a project’s delivery time over all other aspects involved, where the lean method applies in order to have a minimum viable product as fast as possible. Agile methods seem to be the way to go these days. On the other hand, technological evolution itself has led to a great increase in processing capacity. Even when we all aspire at an optimum code, processing is not the scarcest resource today. Increasingly lighter communication protocols like REST, and service-based methodologies, have been an ideal condiment for a strengthened revival of RADs.

What should a RAD include today in order to be valid?

This question results from the variety of tools available in the market. Many of them are startups and others are products that have remained through the years. It is important to consider some aspects for making a decision. Here are some that come to mind:

• Tools that prioritize model over code. The possibility of defining a model with at least the CRUD generated automatically is absolutely necessary, so no time is lost on things that may be automated.

• The possibility of using code is also important because not everything may be modeled in a graphic manner. We should be able to declare extremely complex processes, and doing it graphically does not seem possible. The code should be either proprietary or standard like JS.

• The possibility to deploy the application to production in a simple manner, regardless of its complexity or technology. The time to market is vital these days.

• The possibility of prototyping in a simple manner, again, with the concept of the lean method.

• Working with different clouds, both public and private.

• Capability for reading and exposing services, particularly REST.

• Capability for interacting with several databases.

• Possibility for native interaction with ERP, CRM, and other world-class systems.

• Possibility for testing on the applications generated.

• Having a collaborative working method.  

• Enabled management and control of the application’s rollout, chances for rollback, etc.

• Possibility for generating applications in web and mobile environments, preferably in a native manner for the mobile segment.

• Having mechanisms available for building and integrating excellent UX.

• Having a clear idea of what will happen if the RAD is removed… is it possible to continue viewing or am I trapped in a manufacturer runtime?

Another aspect is to consider the company’s support, and to know what customers work with it, and how long the company has been in the market.  

But in case you still feel somewhat suspicious about RAD tools, my advice, based on my work with GeneXus, is that the only way to get rid of preconceptions is by trying. If we define a conceptual test and work on it with someone proficient in the technology to understand the benefits in it proves essential for making the best decisions.

I suggest you make a list of success indicators, like productivity, quality, UX, multiplatform, or others relevant, with a ranking for each tool in each category. And don’t forget to try GeneXus!

 

And in case you are not attracted by any... you can always be part of the 50%, who, in 2020, will still be entering code manually.