The power of an RDL can be seductive, and most of the risks associated with the use of RDLs arise from not recognizing the limits of that power.

Silver-bullet syndrome and overestimated savings. As with other productivity tools, RDLs are prone to gimmickry and exaggerated claims. Regardless of vendors' claims, it is unlikely that even the most powerful RDL will allow you to reduce your end-to-end development time by as much as 25 percent. Be leery of any product that claims otherwise, or at least don't bank on saving as much time as you're promised.

Even if you see through vendors' silver-bullet claims and have a realistic idea of the design- and code-time savings from an RDL, estimating the end-to-end time savings is tricky. See How Much Schedule Reduction to Expect in Productivity-Tool Use for estimation guidelines.

Application to unsuitable projects. RDLs are not well-suited to some kinds of products. Performance of the code they generate is sometimes not adequate to support real-time or shrink-wrap software development, and RDLs sometimes lack the flexibility needed to implement customized user interfaces, graphics, output, or interfaces to other programs. Sometimes your requirements will call for functionality that the RDL should support, but you find out well into your project that the RDL doesn't support that functionality after all. RDLs work best when your requirements are somewhat flexible, allowing you to play to the RDL's strengths and to avoid its weaknesses.

Failure to scale up to large projects. RDLs frequently lack the software-engineering features needed to support large projects. The same features of the language that seem so convenient on small projects (such as not having to declare your variables before you use them) can create nightmares on large projects or team projects.

Here are some common weaknesses:

To minimize the risk of failure to scale up, before you put an RDL into use on a large project, conduct a feasibility study to be sure that the RDL's software-engineering weaknesses won't cost your project more than it will save over the development and maintenance cycle. Be conservative in estimating the savings you expect to realize. RDLs usually save time, but if the project is large enough to make the schedule an issue, it is large enough to be cautious about an RDL's limitations.

Encouragement of sloppy programming practices. With traditional programming languages, you tend to build infrastructure into your program to anticipate areas that aren't well-supported by the language itself. You develop highly modular code so that changes won't ripple through your program. You use coding standards to make code readable, and you avoid known worst practices such as using GOTOs and global variables.

One of the ironic weaknesses of RDLs is that in pushing back a lot of complexity, they lull you into a false sense of security—they make you believe they will do everything for you automatically. You can get far into a project before you realize that you even need things like design and coding standards. By the time you realize that you do need them, you're so far into your project that it's hard to retrofit your code with them. When you hit the wall, you hit it hard. Your work slows to a crawl, and you might find yourself wishing that you were back in 3GL land.

This experience is so aggravating that some developers claim that you don't really save time overall by switching to a higher-level language. Sometimes that claim is right. The quality of some RDLs is poor, and sometimes RDLs fail to scale up well on large projects.

But other times the problem is not so much the result of the RDLs' weaknesses as it is of the tendency to use sloppy design and coding practices on RDL projects. In that case, the bad experience is more a result of the aggravation people feel when they run into an RDL's limitations and have to slow down. It's like what you experience when you've been driving at 65 mph for hours and then hit a 25-mph speed zone. You feel like you're barely moving. You feel like you could jump out of the car and jog faster. But of course you can't really jog faster than 25 mph, and you usually can't develop whole programs faster in C or assembler than you can in a good RDL.

To avoid the risk of sloppiness, use design and coding practices to compensate for the RDL's weaknesses. If you must err, err on the side of overdesigning your program and being too careful with your coding standards. This is a classic case in which an ounce of prevention is worth a pound of cure.