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 :
- Nokia and Symbian : Business and Software : Lessons To Be Learnt
- What Apple taught other businesses tonight.
- Flash and Runtimes on Mobile Devices, Who is right? Steve Jobs or Adobe?
- MySQL is gone. Here comes MariaDB and Drizzle.
- Is Open Source software a classic example of fail for Design by Committee?
- Why a ‘Single Line’ was added to the Solaris Terms of Use by Oracle?
- Oracle starts to monetize Free Software, is it wrong?
Zero Lines of Code 
The blog is really nice one and full of information we appreciate the kind of information you have provided in this post. The information are o useful for all of us and we would like to thank you from the bottom of our heart for this wonderful information.
yes RAD can be a valuable tool and your list show it’s power and problems.
Mastering generated code, productivity gains and limits, work around of limits etc.. is a big investment.
The issue is the same as with frameworks : there is a hope that this big learning curve can be avoided and that’s a danger. Also there is the fear that the investment to master the tool may end up in the conclusion it does not fit the needs. that’s depressing…
the conclusion for me, is that it needs a strong will, and dedication to use a RAD tool or a Framework to it’s full capacity.
The temptation to do half of the effort leads to poor experience and feed the FUD.
The sale person willing to sell the tool fast, the manager willing to save money or the urgency of a situation are strong factors to adopt those tools in the wrong way.
Who needs RAD? I have Microsoft Access. Soon I’ll have LightSwitch!
Hehe.. yes you can get a long way with Microsoft Access and even Excel, though maybe not suitable for many scaling environments. Anyway, it’s a great article on the benefits and misconceptions of RAD tools.
—
Regards, Jimmi Andersen
http://appFlower.com
Thanks Jammie 🙂