The philosophy of RAD

I love RAD (Rapid Application Development) development tools, a proud tradition that started with VB and lives on through, among other tools, B4A. I love how they let me get down to business without getting in the way, and get fast results. I'd thought I'd share some of my philosophy on the subject of a RAD tool.

* RAD is the sweet spot between "Why doesn't the tool let me do this?" and "Why does the tool force me to do this?".

* RAD is when you don't have to think "Why do I have to do this, the tool should be able to do this for me?".

* RAD is focusing on making the things you usually do simpler to do, even if it's sometimes at the expense of seldom used stuff.

* RAD is minimum bureaucracy. You only need to tell the tool what it can't figure out by itself.

* RAD is for when you are paid for results, not by the hour.

Thoughs? Additions? Criticism?

I agree with these statements. Another important point is that a RAD tool should go with you "hand by hand" while you gain experience.

Good point. It's a tool you can grow with. You can start out easy, but it should still be capable enough for advanced stuff.

Some points I forgot to mention:

* It should be highly integrated. You shouldn't have to jump around in different tools, and the various parts of it should work more or less seamlessly.

* Readable language. The focus should be on readability, not compactness or some "computer science ideology orthodoxy". For example, I'm perfectly happy to sacrifice some of the more esoteric elements of OO (say, for example, operator overloading) for more readable code.

* When you work, you should be able to focus on the problem you are actually trying to solve. You shouldn't have to do a lot of extra "paperwork", "cleanup" or other things that detract attention from the core problem. You know what I mean, in some tools, you need to declare a class and implement various interfaces just to receive an event... Forcing the programmer to jump through such hoops detracts attention from the main problem, and, in the long run, causes solutions that are worse than they should be.

* Fast edit-compile-test turnaround time. Every extra second means less tests are made, and eventually bad code. (By the way, I loved the VB immediate Window, as it allowed me to test a function without writing any stubs or running it in a context. Just type (for example) ?GetPath("c:\dir1\dir2\file.ext") and get the result. Testing it with a few relevant test cases and you're done. One of the best features of VB.)

* Good supporting components/libraries. You do not want to re-invent the wheel, so if you, say want to access a database, play a video or send an email, you want components/libs that does it for you.

I agree and add:
RAD to software is like construction to civil engineering, is like assembling to mechanical engineering, is like logic design in electronics.

The most inventions have been made by "RAD". Today everyone wants to have a plan before they start. If nature would have done this million years ago we all still live as a boring cell in a puddle of mud

* RAD is about getting the job done.

Another one:

* RAD does not force you to plan everything in advance. You can (at least to some extent) make things up as you go.

Erel said:

* RAD is about getting the job done.

Click to expand...

Ditto

RAD? Why are we concerned about RAD in a forum devoted to Anywhere Software's products?
The right acronym here should be BFD for Blazingly Fast Development!

Anyone here experienced the pleasure to have a functioning app within a couple of hours from their first installation; and I am not talking about the hello world program...

To me RAD is what I experienced in the early 80's with Borland's Turbo Pascal 2.0 (that one for sure..I can't recall about version 1.0 but their gold digger advertisement is still clear in my mind..and with time and luck also in an old magazine somewhere in the garage.. hehe).

Umberto

BFD... I like it!