From the Trenches
Directions / Commentary
What RAD Really Means
I’ve seen the term RAD thrown around a lot. Usually, it’s in reference to some problem that Delphi didn’t solve with a wave of the mouse and a double-click. This is then followed by a statement along the lines of, “This isn’t RAD.”
RAD, which stands for Rapid Application Development, is a lot of things. It can go to the very heart of the development process to help teams reach their goals in a more timely manner by combining many different techniques, such as prototyping and CASE tools.
RAD is not a silver bullet that transforms anyone who can open a development tool into a productive programmer. As much as Delphi does, there is always an entry price. Delphi does as much — or more — to obscure the gory details of Windows API programming as any tool on the market. Especially when you consider the flexibility that Delphi allows; it gives you the power to actually delve into the depths of the API, if you so desire.
Perhaps the amount of success a developer obtains by getting a prototype up instantly actually works against Delphi. By this, I mean someone codes an application that’s “done” almost immediately. When they have trouble bringing the application to completion, the tool is suddenly looked at with disdain. “This isn’t RAD.”
When the initial euphoria of the prototype wears off, and the programmer wants to go beyond the cursory, a higher level of knowledge is required. A programming tool such as Delphi cannot shield programmers from knowing how to program.
As in life, Delphi’s strength probably contributes greatly to its weakness. Because Delphi does successfully prevent developers from having to recall vast tidbits of trivia relating to the Windows API, a functioning application can be built in record time. Because Delphi can take them so far so easily, some developers feel cheated when it can’t take them further without becoming familiar with the tool and environment.
The 80/20 rule in software programming has existed for many years. This rule states that 80 percent of the application will be coded in 20 percent of the time. My argument is that Delphi gets you to the 80 point quicker than any other tool out there. Period. Furthermore, I also believe that finishing the last 20 percent of the project with Delphi is at least as fast as other tools. The results are magnified if you compare the same development techniques and planning across tools. It’s not fair to point the finger at Delphi when there wasn’t any planning. A project like this would inevitably encounter a rough spot no matter what tool was used.
Perhaps an example using the classic building analogy would more clearly illustrate what I’m talking about. If I was a building engineer and a tool came along claiming to build houses in record time, I would definitely evaluate, and probably use that tool. But that would not preclude me from having to know the underlying fundamentals of building design and construction, especially as it pertains to the local building codes. After all, I wouldn’t want to build a house in Wisconsin based on Southern California needs. I would also have to know how to solve problems by picking up a hammer and pounding a nail in the right place if the tool didn’t do it properly.
Using Delphi, programmers will typically see an increase in productivity. However, to fully realize the benefits that Delphi can bring to your shop, you must look beyond what a tool provides. You must
look at how that tool can fit into your overall development efforts. For more information on how to turn your shop into a “rapid development” shop, refer to Steve McDonnell’s Rapid Development [Microsoft Press, 1996, ISBN 1-55615-900-5].
Dan Miser is a Design Architect for Stratagem, a consulting company in Milwaukee. He has been a Borland Certified Client/Server Developer since 1996, and is a frequent contributor to Delphi Informant. You can contact him at http://www.execpc.com/~dmiser.
Mr Miser explains the true meaning of RAD as it relates to Delphi.
Mr Miser explains RAD.