RAD is known as Rapid Application Development. Programs such as Visual Basic, Delphi, Dreamweaver, and similar visual tools are examples of RAD.
What I've found is that RAD is interesting, and useful in many cases - but it actually is not required. For example, RAD does not determine whether a software project is going to be launched or not. RAD doesn't make our lives a million times easier. It makes our lives easier in certain situations - but it is certainly not as required as some people think it is.
Programmers who have such passion for programming, and such addiction for programming - can get by without RAD. We can find other ways to automate our program construction.
Programmers that only use RAD do not have enough motivation yet to automate program construction in other ways. For example, some people fear make files and command prompt automation. Don't get me wrong - a make file and a command prompt are no replacement for rad - nor am I command line zealot. But there are ways to automate projects other than RAD. Sometimes, RAD isn't as important as other forms of automation.
This is how I see RAD: it is one form of automation that makes programming easier. But RAD doesn't solve all the problems - it is just one form of automation.
As programmers become more and more experienced - we like figuring things out the hard way. Some programmers are guilty of bashing rad because rad is too easy. This is just because they like doing things the hard way in order to find similar ways. For example, a lot of programmers that bash RAD are fans of make files - but how can we bash rad, if make files are also a form of automation?
Many times the problem with RAD is that the IDE that handles the RAD is too buggy, or has minor glitches. All major RAD tools have always had some glitches, bugs, or work arounds that restricted programmers in a way. In some cases, these restrictions and glitches could be worked around. In some cases, they could be worked around and combined with other forms of automation at the same time.
Let's take a real world example:
Suppose I have a RAD IDE open. Suppose that i have several projects that I need to compile in one shot, because these projects work together with each other. Pretend I have 5 DLL's or DSO's (dynamic link libraries or shared objects) and 3 executable files that I need to compile. These executables and dll files all work together when the main program is running.
Sure, RAD will help me build some GUI stuff for these projects quicker and cleaner than programming the GUI stuff from scratch. But let's say that the IDE does not have a feature that let's me compile all 5 DLL's at once, along with 3 exe's.
Here, RAD doesn't help me solve all my problems. Other forms of automation will be needed. Usually, a make file or automatic compilation script/program does the job. If the IDE has a makefile generator, sometimes this can work - but sometimes the makefile generators are buggy or they do not create all that is needed. So a motivated programmer wants to learn how to do automation for things other than just RAD. Even if RAD is useful, usually a programmer will end up in a situation where other forms of automation are going to be needed.
The purpose of this article: to inform those that one cannot be a pure "RAD" advocate and think that RAD is the end all solution and holy grail. Be motivated enough to do some things manually - in order to reap the benefits of automation. For example, some people are too lazy to manually set up their IDE TOOLS menu. The irony is that some manual intervention leads to automation. Why is it ironic? Because the word "automation" is the opposite of "manual" - yet they compliment each other.
A motivated programmer will have no problem constructing a makefile from a bare text, because he wants to learn about automation and master automation. Again, ironically, manually building the make file in a bare text file is not automated - but once you build that makefile, it creates automation.
Better yet, makefiles suck.. a build system designed in a proper language (such as the FPMAKE build system or my Powtils build system that I wrote) is better than make files. But making your own build system is tough in the beginning stages.. so try reuse an existing one like FPMAKE or my build system in Powtils. There are also python build systems that I have not tried.
A motivated programmer may also construct a batch program, or a batch script to take care of compiling several projects at once. A non-motivated programmer with less experience will continue to struggle compiling each project separately.
Someone stuck in the RAD syndrome, who thinks that RAD is the end all solution, will many times not be open enough to other forms of automation. It's not that other forms of automation replace RAD - it is that they compliment and offer different advantages than RAD.
The other area I've seen where people are stuck in one mode of thinking, is linux shell scripts. Many times it takes just as long to construct a linux shell script, as it does to construct a program in Pascal, C++, Ada, Python. Rather than a batch script, some time be brave and motivated and make a program in your language that you want to use. Who said that your batch had to be a script? Your batch can be a program, too you know!
Be open minded enough to jump outside that one line of thinking - whether it an obsession with RAD or shell scripts, you can find other forms of useful automation. RAD is just one form of automation - it is just one tool. It does not solve all the problems.
Why do you think people have been creating powerful applications in Visual C++ for several years, even though Visual C++ isn't all that RAD as Visual Basic or Delphi? Good applications can still be built without RAD - good programmers are such motivated and ambitious people, that they can actually find building programs fun whether there is RAD or not.
Those who exploit the advantages of RAD, but leave it's disadvantages behind - are usually even better programmers than the ones who bash RAD or believe only in RAD. For example, some people prototype quick applications using RAD, but then in the larger application they don't use 100 percent RAD. Taking the RAD stuff and turning it into manual stuff they can edit, is exploiting RAD - but leaving its disadvantages behind. Some start off developing a RAD application, but find as their program gets larger, the RAD is less important in some areas, but still important in others. The point is to exploit the advantages of RAD, but not to use it as if it is the one and only winning solution.
Aside Notes
Not as related to RAD, and a bit off topic for this article, but..
Another example of exploiting the advantages of two ideas, instead of being a slave to one - the GUI versus CLI. I love to exploit the advantages of GUI and exploit the advantages of command line. For example, I use Total Commander when on a Windows machine, but also open up a command prompt in certain directories - since total commander has a command prompt launcher box available at the bottom if you enable it. Command prompts are very simple, and because they are very simple they are not good for doing every day complicated human tasks. I can control a two pane file manager with my keyboard faster than I can control a command line, and get visual feedback while I'm controlling the panes. I can apply filters to the panes immediately, interactively - while in a CLI it is fragmented to try and apply a filter to a directory and then hit LS or DIR.
Some command line zealots will argue that you can get visual feedback by simply typing in DIR or LS, and that you can type much faster at the command line than you can control a GUI with the mouse. These zealots are not exploiting the advantages of the GUI and the CLI together - and they are not exploiting the advantages of a keyboard controlled GUI. they are slaves to the CLI. There are also those who are slaves to the GUI. Those who exploit both the GUI and the CLI together are the more successful ones.
Another example of being stuck in one mode of thinking, is those who use Regexes way too often. There are many cases where writing a procedure or function is more productive and more maintainable than a regex. In other words, some people don't even think past regexes - they think that parsing text is using regexes. A motivated programmer will write a parser that doesn't make use of any regexes, in order to learn and become more advanced with other forms of automation. Writing your own parser without using regexes is just a form of automation which you had to manually write. Writing a regex is another form of automation which you had to manually write. But regexes are not the one and only way to parse text, and they are not the best way to parse text in all cases. If you know your language well enough, you can write some parser functions in just a little bit more time than you can whip up a regex - and although it takes you a bit more time, it can be more maintainable than a regex.
|
