In a pleasantly provoking post Jeffrey warns us against the dangers of RAD. What RAD stands for in his eyes is not to clear. Jeff's post makes clear it is a sliding definition. I cannot state things better than Jeff's final comment. But as the RAD acronym has a long history in my career, with many a bright side, I would like to add my 2 bits.
The first PC's were no more than a calculator on steroids. They could be programmed but the gap between the programs tools and the customers problem domain was gigantic. Quite a step was dBase. In it's programming language you could code something like
@ 2, 10 SAY Customer->Name
The first PC's were text-based, this statement would display the customers name on text row 2, starting at column 10. In many a language before that you had to copy the string byte by byte to a very specific location in RAM, the address corresponded to a location on the screen. The next byte would set the character's color, the byte after that the next character and so on. So the @ 2, 10 SAY statement was a RADical improvement.
dBase also brought the first way to work with structured data. It's so much easier to just code Customer->Name instead of copying something out of an obscure IO buffer. But checking the uniqueness of primary keys and the validation of foreign keys had all to be done by hand in dBase. It took the arrival of Access 1.0 and sql server connections to the desktop to relieve you of that burden.
Windows brought graphical forms and real form designers. The first tools worked with resources; you had to do the @ x,y in there. With Access, Delphi and VB came the visual form designers making the once so RADical @ x,y obsolete. Drag and drop designers also took a great flight for non visual items like database operations. When you look at datasets in VS 2005 it's loads and loads of (generated) code whose content is steered by setting properties in the visual designer
Somewhere in this history the term RAD popped up. It could stand for Rapid Application Development or even Rapid Application Design. It was welcomed as a good new thing, a radical change. Using drag and drop the craftsmanship of the developer who knew how to find his way on the CRT-screen was obsolete, now every idiot could create a program. And many an idiot started creating programs.
But a fool with a tool is still a fool. You can setup database interaction very quickly in a dataset but when the connection string to the database is hard coded inside the app just will not work on the customers machine. VS 2005 tries do do a good job here, as its RAD-wizards try to redirect the connection string to the app's config file. Even worse are monolithical apps. Here VS 2005 really loses it. It will suggest dropping a SQLdatadapter straight on a web form. So all code of your app, from the database connection to the presentation HTML ends up in one solid rock. This is where I completely agree with Jeffrey, this kind of software is un-testable and un-maintainable.
A prototype built this way always ends up in the waterfall of all other over-specified documents in the start of a project. But in the course of the project, working with the customer, I still very much rely on all visual designers to navigate through and organize the code. Am I still doing RAD ? Looks like it. Is it bad ? I don't think so. RAD is as powerful a tool as a chainsaw. Very effective but very dangerous if you don't know how to handle it. On the other hand, RAD is just a marketing buzz-word to me and nice for a little rant.