RADically speaking

Just to be sure we`re talking about the same thing, let me outline a working definition of rapid application development (RAD) tools.

I`m not knocking the tools per se, but rather the style of development that they tend to promote.

A RAD tool is a software development tool that supports the ability to graphically render applications through dropping standard components onto a work area. RAD tools typically provide a means of "hooking" visual components directly to a database.

Some examples of RAD tools include Visual Basic from Microsoft, PowerBuilder from Sybase and Delphi from Borland.

The theory is that it is easy and quick to build data display and entry forms using the standard components that ship with the tool. Simply choose the components such as buttons, edit boxes, drop down lists etc, drag and drop them onto a form, link each control to the appropriate bit in your database and presto, instant gratification!

Sounds great, doesn`t it? It`s almost too good to be true. Well, in my opinion, it is too good to be true. To quote my favourite acronym: TANSTAFL (There Ain`t No Such Thing As a Free Lunch). This ease of application development comes at a cost. Unfortunately, the cost only starts to become apparent much further down the line, when the cost of change is punitive.

Don`t get me wrong, I`m not knocking the tools per se, but rather the style of development that they tend to promote. They promote a style of development that starts by throwing together a few good-looking screens, slapping a database into some sort of shape and then hooking it all up under the covers.

This is the message the vendors of these tools would like you to swallow. If you take the time to look a little deeper, you`ll discover the sordid truth! To use the doghouse analogy quoted in "The UML User Guide" by Grady Booch, it`s easy to throw a doghouse together that will make your dog happy. If you get it wrong, it won`t cost you much to fix it either. Building a house for yourself is also not that difficult; you could possibly manage it with basic plans and a few good builders. A serious skyscraper is a different prospect. Do it without proper architecture design and planning, and you`ll find yourself in serious trouble.

It`s a question of scale. For building a small application RAD is good. These applications are typically relatively simple and are built to purpose to solve a well-understood and well-defined problem, normally on the sort of scale of a doghouse.

Larger projects, on the scale of a house, may also work reasonably well. Except that when you discover that you`d like to add that extra room, you may find yourself having to break down a bit of the original house first. Costly, but possibly worth the risk since adding rooms is not something you do that often.

Building a skyscraper, even a little one, is a different prospect. Your natural response is possibly along the lines of: "I`ll get a good project manager and watch it closely." Unfortunately, this will not be good enough. A large project takes serious investment. They key to success is risk management, identifying these risks early means exploring the problem in a great deal of depth without going near a RAD tool. Once the problem is well understood, you`ll be in a position to begin understanding the solution.

This goes against the grain for traditional RAD programmers. Why bother thinking about it when I can simply slap a few screens together and hook them to the database.

So you`ve built your skyscraper the quick way using RAD. It works, it meets the business` requirements and everybody`s happy, right? Wrong! Well, your developers are on a cool new project using this and that fancy new technology, but the business has just restructured all of its business processes. You need to change your skyscraper accordingly. This is where the s**t hits the fan.

You discover, too late, that the lack of a coherent architecture and its documentation means that none of your developers fully understands the impact of change to the system. You begin to experience the dreaded ripple effect, where a change in one area breaks something in a seemingly unrelated part of the system and maintenance costs begin to exceed the cost of enhancements.

In my opinion, the tools themselves are not the culprits here. Rather, the vendors whose marketing message is seriously misleading combined with the gullible managers who believe it, are to blame.

The reality is that RAD tools are not a substitute for a formalised and well-managed development process. They improve productivity in a few limited areas during the construction phase of a project. Unstructured use of their many cool features is likely to lead to worse problems than the lack of RAD tools in the same environment.

RAD tools do offer some compelling features. Do not be fooled, however. You must still manage the development process properly and architect the solution correctly. Resist the temptation to build "prototypes" unless you have made it clear that they are prototypes. When users see the screens, they believe the application is mostly done and fail to understand why it`s taking you so long. This creates unrealistic expectations that lead to additional deadline pressure and the associated fall off in quality.

Treat your RAD tools no differently to other development tools. They are not the silver bullets the advertisements are designed to make you believe they are. If you do this, then RAD all you like!