Rapid Application Development

RAD is an acronym for Rapid Application Development, a style of development made possible by VisualBasic Smalltalk and BorlandDelphi and others, which usually contain all of the following capabilities: Philosophically RAD has its origins in the Smalltalk language/environment. The RAD philosophy of software development either flies in the face of the old idea of writing a prototype and then throwing it out (PlanToThrowOneAway), or else it breaks PlanToThrowOneAway into smaller, more manageable component-sized chunks. The idea is use a language like SmallTalk or BorlandDelphi or VisualBasic, and then after the prototype, instead of chucking the prototype and starting over in C, you iterate on the prototype until you have a finished high-quality product.

This is criticized by some as encouraging sloppy development, and encouraged by others as being a way to develop programs more quickly and cheaply, without the attendant difficulties of writing GUI applications in the older more traditional ways.

What is an example of sloppy development that it encourages?

What is there to be said in favour of throwing one away?

What can be said on each side with regard to learning to use one of these tools?

This isn't the definition of RAD I'm familiar with. It's nothing to do with tools, it's an approach to development. ExtremeProgramming is a form of RAD to me (and so is DSDM). For me it's the quick delivery of something then successive iterations adding functionality. I would normally expect this to be for custom software development rather than (shrink-wrapped) product development.


I think that most RAD tools are pretty suitable to use a GlueLanguages, but I don't care for the RAD concept that much, maybe.


I am fascinated with the concept of using DataDictionary and/or EntityRelationshipDiagram-like tools to generate the vast majority of CrudScreens and related behavior for business applications. The patterns and behaviors are, or can be, pretty consistent in CrudScreen applications. The trick is making a way to integrate custom stuff into it when the default behavior is not sufficient. I would have to study more exceptions to see when and why such exceptions are made. I suspect that they are usually the capricious whim of somebody rather than a rational requirement. It gets into the highly philosophical area of whether or not TheCustomerIsAlwaysRight?. But, as it stands I believe I could create such a system that can crank out fairly complex applications just by filling in DataDictionarys and maybe adding a few event handlers here and there. It would include fairly sophisticated QueryByExample screens also. It would use a kind of "stack" behavior of unfinished screens so that the user could go and look stuff up without being forced to finish or cancel the current screen. A list of pending screens would be always displayed. It is my attempt to compress the common behaviors and needs of business applications into a fill-in-the-blanks setup. I don't think such a system would be easy for most developers to learn, giving its declarative nature, but once they do learn it they could build many applications rather quickly, I believe. -- top


Link - Emacs + SQLite as RAD platform http://mysite.verizon.net/mbcladwell/sqlite.html


Popular RAD Tool List:
See also: TheRadBottleneck, DynamicRelational

EditText of this page (last edited June 30, 2014) or FindPage with title or text search