When To Use Rapid Application Development

Source – Public Domain, 1997

Rapid Application Development, or RAD as it is popularly known, is a well established methodology that has served the IT community well since its inception as the ‘Spiral’ development process of the 80’s. Unfortunately, it has also done a fair share of disservice to overzealous project stakeholders due to its misconception as a cheap shortcut to the formal ‘Waterfall’ development approach. The key to its successful application is understanding its purpose and limitations.

What Exactly is RAD?

RAD is a software development process that combines the Requirements Definition phase or activities with iterative prototyping, allowing useable systems to be produced in a very short timeframe. Instead of the usual Analysis, Design, Development, and Implementation phases, RAD employs only Prototyping and Deployment as its key phases (sample the IT-Project-Templates.com project plans for complete Waterfall and RAD activities and deliverables).

Pros and Cons of RAD

Clearly, the key advantage of RAD is its time and cost saving, a key consideration for resource constrained and/or compressed project timelines. Also, RAD allows quick visibility of results to the stakeholders and, in situations where they were not sure exactly what they wanted, helps define requirements. But there is a trade-off for these advantages.

The biggest drawback is Quality. Because of the ‘quick and dirty’ approach to development, defect rates tend to be high. More importantly though, quality is often sacrificed in terms of an end product that is less integrated, less fully-featured, or less efficient. RAD projects are usually built using CASE tools and reusable components which may or may not adhere to the enterprise architecture standards. They may be fine as stand-alones, but may fail when they interface with existing systems. Furthermore, many RAD projects are not upwardly scalable. Oops!

When To Use RAD

Some key guidelines for when to use RAD are:

• When development time is critical, or when a product is needed now before things change
• When stakeholders are not sure exactly what they want other than some basic requirements
• When Quality is negotiable

When Not To Use RAD

Some key guidelines for when NOT to use RAD are:

• When stakeholders think they will save a lot of money using RAD
• When stakeholders are not willing to compromise on Quality and will not allow secondary requirements to be ‘timeboxed’ out of the development iteration
• When project management will not accept informal project deliverables
• When the product must support or interface with other critical systems (reliability and performance are not critical)