Agile, SCRUM, Kanban, Waterfall, RAD, frameworks, and methodologies. Do you ever feel like you’re drowning in niche phrases, acronyms, and terms of art? If you have that feeling, especially in the software world, you’re not alone—you’re not wrong either.

You have a release date set and a team ready to work. Now all you have to do is wade through the methodologies and frameworks to figure out where to begin. Is waterfall the way to go? After all, it’s got the longest track record. What about Agile? Your friend the project manager tells you it’s changed their life for the better. The bottom line remains, you have software to produce and it would be helpful if you knew which set of steps to follow. That’s what we’re here for—to outline some of the methodologies and frameworks to help you make a decision and get to work.

First up, we’re diving into the term RAD, which stands for “rapid application development” and is one of the most descriptive names imaginable. RAD is literally a way to shorten the development cycle and, well, develop your application rapidly.

RAD vs. Agile: What’s the Difference?

While we’re still on the topic of words and phrases and how they can either confuse or clarify, we’d like to take a moment to define some specific terms we’ll be using. It’s important to have context about the environment in which an acronym came to be used in order to have a fuller understanding of the concepts being described. For RAD, that context is the broader world of the software development lifecycle or SDLC (which is, in case you were wondering, chock-full of acronyms).

At the same time, there is much confusion out there between RAD and Agile. We see these terms used interchangeably all the time, and would like to start by clarifying the differences. But first, we need to go back in time to where it all began.

Waterfall methodology

To understand RAD, you first have to know what “waterfall” is. The waterfall methodology was originally borrowed from engineering, and it ultimately became the first official methodology for software development projects. This approach is linear and sequential, moving from one stage to the next in a regimented order and in only one direction from planning through to completion and delivery.

The primary focus of waterfall development is on the early stages of requirements planning and documentation, with no allowance for user input or feedback during the latter stages. While easy to understand and implement, this model suffers when team members leave mid-cycle or there is a need to pivot or adapt to changing requirements (as is common in software development). Thus, developers have had to adjust and adapt these basic ideas over time, resulting in the newer, shinier methodologies that are popular now. 

Rapid Application Development—RAD

Beginning as a response to the perceived stifling nature and lack of ongoing feedback inherent to the waterfall model, by 1991 the rapid application development approach had been finalized with the publication of James Martin’s book by the same name. With a heavy reliance on prototyping and incorporating user feedback throughout the development cycle, RAD quickly overtook waterfall as the development model of choice for software projects.

Agile software development

Often used interchangeably with RAD, agile is actually a much broader project management framework. The processes of the Agile methodology can be found in other IT projects as well. With a history going back just about as far as waterfall, Agile was not solidified into a concrete thing until the publication of the Manifesto For Agile Software Development in 2001.

Incorporating many of the same tenets as RAD, agile sought to expand the ideas of speedy development cycles, integrated user feedback loops, and continual improvement to a broader context. And judging by the wide variety of sectors it is found in only 20 years after inception, we’d say it’s been a success.

How RAD Can Speed up Your Development Cycle

On to our focus for today, rapid application development, or RAD. The name RAD is found in two main contexts today. First and most often it’s used to describe any SDLC that adheres to what is actually an Agile approach. And second, it is the formal name for the methodology laid down by Martin in 1991. The fast development cycle turnaround, active user feedback, and cross-functional teams are endemic to both, so the mixed use is completely understandable.

We’re going to use RAD to refer specifically to Martin’s methodology, and we’ll use Agile for everything else in the interest of simplicity. James Martin developed RAD in direct response to what was widely perceived as the stiff and regimented nature of the waterfall model being used to govern software development projects at the time. He saw the lack of user feedback and long, drawn-out planning phases as a potential weak point for software projects and wanted to define a process that would be faster and more able to pivot on little notice when requirements changed.

What he landed on is a framework for structuring the SDLC that incorporated a heavy dose of prototyping, feedback loops, and pushes that still exists in nearly every company that’s turning out software today. Martin’s model had 4 basic stages:

• Requirements planning
• Prototype
• Build
• Finalize/release

This series can, of course, vary by project or company, but that’s the basic outline. In many cases where this process is visualized, the second phase (prototype) is depicted as a smaller cycle within the larger one consisting of prototype > feedback > iterate > prototype, etc. This allows for the incorporation of user feedback into the final product without disrupting the overall SDLC flow or affecting the timeline for release.

It’s this heavy focus on prototypes and feedback loops that is probably the #1 differentiator of RAD projects. By allowing for the integration of feedback during this early stage, not only can the final product include fixes and features requested mid-cycle, but reviews upon initial release are universally more positive as well. 

Key Features of the RAD Model

So how does all this impact your SDLC? Or should it have any impact at all? As part of a larger Agile framework, implementing the RAD model brings with it many benefits:

• Faster turnaround. RAD software projects can often be completed in as little as 2-3 months as compared to 6-12 for similar waterfall projects.
• The Iterate > test > fix > iterate cycle allows for feedback to be worked into each iteration.
• Uses public feedback as an integral part of the development cycle. This can cut grief and limit headaches at cutover as all features have been incorporated already.
• Allows large projects to be broken down into smaller, more discrete tasks that can be assigned to the most appropriate team member. These tasks can also be reassigned easily should there be turnover mid-project.
• The constant feedback loop between stakeholders and production team members means a more efficient overall SDLC as well as a higher likelihood for a successful cutover since, again, the customer has been involved with feedback from the early stages.

When to Use the RAD Model

As with any framework or methodology, there is a right time to implement RAD, and there are some times when another model might be the better option. Some factors that indicate RAD is the way to go:

• When speed is of paramount importance
• When you have a good budget and a known team
• When you have a pool of testers at the ready
• When your infrastructure can support rapid iterations
• When your infrastructure can support monitoring and management of a fast-paced project

Don’t let a lack of testers on staff deter you from implementing RAD for your next project. With the rise of Nearshoring, you can outsource this task to a trained team of testers by partnering with a technology service provider. The benefit to nearshoring is that your team will be located in your time zone, making collaboration that much easier and speeding up the testing stages.

By the same token, not all RAD development is based on your ability to deploy an army of experienced coders. Some RAD solutions and frameworks and strategies support low-code/no-code development cycles that empower less technical users to build simple applications quickly and easily. While RAD and low-code aren’t interchangeable concepts, they can often work hand in hand for businesses that don’t need extremely complex modernizations built out. 

When RAD Might Not be the Best Choice

As we said, there will be projects where moving quickly is not the most effective way to proceed and you’ll need to consider other models or frameworks:

• When control over the process trumps speed
• When you have a solid team with the experience to follow through on each stage
• When your team is on the small side but has broader experience with less specialization
• Documentation is paramount for the customer and they’re OK with the extra time needed

All that being said, we’d wager that for the majority of software projects right now, RAD is a great option to pursue. The speed at which the overall app world is moving means you need to be able to move just that little bit quicker than your competition if you want to survive. And the ability to know upon release that your customer base will be happy with the product is priceless in that it guarantees happy users right out of the gate. No matter the specifics of your next software project, the RAD methodology is a great way to get your product to market fast.

Learn More About Intertec’s Software Engineering and Support Services

Intertec specializes in building and supporting custom software for its diverse clients. Our experienced team of interdisciplinary professionals have experience at all stages of the software development lifecycle. Click here to learn more. Prefer a personal consultation? Go ahead and schedule a meeting with us here!