Rapid Application Development (RAD) is a way of developing computer software applications with less effort than the traditional means.

RAD tools focus on providing code generation and automated testing capabilities with the use of convention over configuration to provide a streamlined workflow to create applications.

Even with the most advanced and easiest to use RAD tools, there are times which the traditional enterprise and the business software development vendors which are having their own implementations and in-house built frameworks are continuously refusing to adopt them.

Most of the misconceptions on the RAD are based on FUD (Fear, Uncertainty and Doubt) which has been created around the internal complexity of the RAD tools.

Here we take a look at the biggest common misconceptions on RAD tool adoption in the enterprise.

1. RAD tools are magical

This is a common myth among the developers who insist on writing their own code from scratch.

Due to the elegance and the accuracy of properly generated applications, they will assume that the changing of generated code would cause the application to lose its beauty.

They are reluctant to see patterns in commonly developed applications which could be easily generated by the use of RAD tools.

2. You can’t make changes to the generated code

Most of the code generated by the RAD tools are editable, but takes a developer who has the understanding on the related technologies.

When people do not have the exposure to the technologies beneath the RAD generated code, they will start to spread fear and doubt on the customizability of the generated application.

3. RAD tools are for simple applications

Yes, simple applications can be generated by RAD tools, but it doesn’t limit you from creating a large application with the use of the tool.

As long as your application is properly designed, RAD tools will always have a solution.

Agree or not, most of the current applications with support to the cloud are the ones built with RAD tools.

4. You can’t make mistakes while generating the code

Most RAD tools have the capability of correcting mistakes done while generating the code. In most cases, even if you have made a mistake that the tool cannot reverse, there will be a manual way you can correct it.

5. You can’t make complex user interfaces with RAD tools

First, ask yourself whether you really need a complex user interface. The users are really comfortable using a simple, elegant and consistent user interface, rather than a complex and bloated user interface.

Even if you want a complex user interface, you can always integrate your generated code to your own user interface.

6. RAD is for startups, not for big businesses

If you are a big business, you will benefit more from RAD than a startup, because your development and testing time would be significantly reduced due to the reuse of patterns.

Actually, big businesses use RAD, but will not tell you.

7. You can’t integrate RAD applications with other systems

This again is due to the lack of knowledge about the particular application development framework. Almost all of the RAD tools provide means of exposing services to integrate your generated application to other applications.

8. You can’t work in a team setting or use a Version Control System (VCS)

You can always check-in your generated code to the VCS, and work in collaboration. In most of the cases, you just have to make sure only one developer is responsible for the use of tool for a particular module of the application.

9. RAD tools lock you in for a particular technology

Before asking this, ask yourself how much you are locked into the technology which you are currently using.

Most tools provide a humble way to remove the RAD tool dependencies and continue the project as a handwritten project.

10. People who can code should always code, instead of using tools

People who can cook, should always cook? No. Especially when they are given a machine which can create any delicious meal, once the guidelines are defined by the cook? No, not at all.
People, who can code, are the best people to properly use RAD tools, as they understand the tool better, and are able to extend and make the maximum use of the power of the tool.

Additionally, they can write add-ons, application specific and platform specific components to better match the business needs while increasing productivity to the organization as a whole.

11. RAD tools reduces the job security of the developers

This is largely false, as the tool would only increase productivity. Developers would have more time creating ‘applications’ instead of creating ‘application code’. As the tests and the related scripts are automatically generated they would have more time for manual testing of the application and to cater more requirements instead of battling the complexities arising from day to day changes to the application.

12. You can’t maintain generated applications with RAD tools

Before asking this question, look at your own code and see how much legacy code and technologies are still present. One thing you would understand is that application code never grows old or dies. As long as it works, it will be alive.

Using RAD tools, you will always have the particular version of the tool to make changes to the existing code based on the available capabilities. Even if a new version comes along, it will be mostly backwards compatible and would even have capabilities to support the conversion of the existing generated code to the new code to make it better. This is largely possible due to the proper use of patterns in the generated application.

13. RAD is complete

The perfect RAD tool is not yet complete, but the current tools have been evolved over the years and are usually more than enough for almost all businesses. Most tools would provide you ways to enhance the tool in order to better cater for your individual needs.

14. RAD will take your house, your spouse, everything you have and leave you with nothing.

No. Really?

These are just the biggest misconceptions; the rest will be covered in a next post on this blog.

Additional Resources:

Frameworks and Tools

Read more posts on this blog :