Rapid application development: A faster, agile software approach

Though often mistaken for a specific model, rapid application development (RAD) is the idea that we benefit by treating our software projects like clay rather than steel, in the sense that they can be tested and refined, instead of following detailed planning and design phases that are typically associated with traditional development models.

A (very) brief history of RAD

How did RAD programming come about?

In the 1980s, Barry Boehm, James Martin, and others recognized this obvious point: software was not a raw mineral resource. They saw software for what it was: infinitely malleable.

Boehm and Martin took advantage of software’s inherent pliability when designing their development models: the Spiral Model and the James Martin RAD model, respectively.

Since then, rapid app development has evolved to take on other forms and acted as a precursor to agile.

RAD methodology: An overview

Though exact practices and tools vary between specific methods, the underlying rapid application development phases remain the same:

1. Define Requirements

Rather than making you spend months developing specifications with users, RAD begins by defining a loose set of requirements. “Loose” because among the key principles of rapid application development is the permission to change requirements at any point in the cycle.

Basically, developers gather the product’s “gist.” The client provides their vision for the product and comes to an agreement with developers on the requirements that satisfy that vision.

2. Prototype

In this rapid application development phase, the developer’s goal is to build something that they can demonstrate to the client. This can be a prototype that satisfies all or only a portion of the requirements (as in early-stage prototyping).

Explore the concept of clickable prototypes

This prototype may cut corners to reach a working state, and that’s acceptable. Most RAD programming approaches have a finalization stage where developers pay down technical debt accrued by early prototypes.

3. Absorb Feedback

With a recent prototype prepared, RAD developers present their work to the client or end-users. They collect feedback on everything from interface to functionality—it is here where product requirements might come under scrutiny.

Clients may change their minds or discover that something that seemed right on paper makes no sense in practice. Clients are only human, after all. With feedback in hand, developers return to some form of step 2: they continue to prototype. If feedback is strictly positive, and the client is satisfied with the prototype, developers can move to step 4.

4. Finalize Product

During this stage, developers may optimize or even re-engineer their implementation to improve stability and maintainability. They may also spend this phase connecting the back-end to production data, writing thorough documentation, and doing any other maintenance tasks required before handing the product over with confidence.

Rapid application development advantages

A rapid application development methodology makes use of these four steps to help development teams reduce risk and build excellent products. But there are other advantages to RAD.

• Speed: In the traditional waterfall approach, clients would invariably change requests, from interface to functionality after first delivery. With RAD, projects are more likely to finish on time and with client’s satisfaction upon delivery.
• Cost: While in waterfall, the risk of IT building complex features that the client may choose to get from the final product is high, in rapid application development, developers build the exact systems the client requires, and nothing more. The time spent building zombie features can never be recovered, and that means the budget spent on them is lost. RAD programming reduces this risk and therefore reduces the cost.
• Developer Satisfaction: In the traditional waterfall approach, developers work in silos devoid of feedback and positive affirmation for a product well-made. And when they finally get the opportunity to present their work to the client, the client may not roll out the red carpet for them. Regardless of how proud developers are of their work, if the client isn’t satisfied, developers don’t receive the accolades they so desperately seek. In a rapid development environment, the client is there every step of the way and the developer has the opportunity to present their work frequently. This gives them the confidence that when the final product is delivered, their work receives appreciation.

Rapid application development disadvantages

Those advantages sound pretty rosy, so let’s douse this warm positivity with a cold splash of reality.

• Scale: A close-knit team of developers, designers, and product managers can easily incorporate RAD practices because they have direct access to one another. When a project expands beyond a single team or requires inter-team communication, the development cycle invariably slows and muddles the direction of the project. Simply put, it’s difficult to keep a large group of people on the same page when your story is constantly changing.
• Commitment: In waterfall, the client spent most of their time apart from the development team after completing specifications. This allowed clients to focus on their primary tasks and developers to focus on building. In a rapid application environment, the frequent cycle of prototypes requires developers and clients to commit to frequent meetings that, on the outset, may appear to consume unnecessary cycles.
• Interface-Focus: Rapid application development methodology motivates developers to find the perfect solution for the client. The client judges the quality of the solution by what they can interact with—and often, all they interact with is a facade. As a consequence, some developers forego best practices on the back-end to accelerate the development of the front-end-focused prototype. When it’s time to deliver a working product, they patch up the jerry-rigged server code to avoid a refactor.

When should you use a RAD methodology?

With the pros and cons of RAD programming laid out, let’s determine which types of projects benefit most from the rapid app development approach.

If you’re building an internal business tool or even a customer-facing portal, like an app or website, rapid app development techniques will help your team deliver a better experience to your end-user.

However, if your team is tasked with building mission-critical software (flight controls, implant firmware, etc.), the RAD methodology is not only inappropriate but also irresponsible. A pilot with a failing control module or a heart attack survivor with a malfunctioning pacemaker cannot offer feedback on your prototype from beyond the grave.

So before you choose a rapid development environment for your project, ask yourself the following questions.

1. Is my product mission-critical?

If end-users place their security or their very lives under your product’s control, it leaves your team with very little room for error, and a rapid development environment thrives only when we allow it to make and correct errors.

However, exceptions exist for products we are able to simulate without placing anyone in harm’s way. But if your project must be 100% flawless before you expose it to the end-user, rapid app development is not the choice for you.

2. Do I have access to end-user and client feedback?

As mentioned throughout this post, rapid app development requires buy-in from the end-user; they must be willing and able to provide feedback as well as subject themselves to user-testing.

As for clients, they must commit to providing frequent feedback during the iterative, on-going rapid application development process.

3. Can I divide my deliverable?

In a rapid development environment, your team exposes the end-user to prototypes early and often, frequently with incomplete or missing user flows. Therefore, you must divide your project such that your team may build and present the product in portions (or modules), rather than in one complete whole. Often, a barrier to modularization occurs on the backend where your project must integrate with multiple third parties before delivering a business use-case to the end-user.

You can get around this requirement by relying on data synthesis, a process that generates fake data to resemble in approximation the data set your end-users expect. This enables you to model behaviors with your prototype without going the extra mile to build connectors in advance of needing them.

4. Can my team iterate quickly?

The final, and most obvious question to ask yourself is whether your team can iterate at a RAD programming pace. Certainly, traditional software techniques generate code more malleable than steel, yet we often build products with bones at their core — breakable, but not without excruciating pain. Boilerplate code, the bare minimum code which forms the skeleton of our project, consumes a non-zero percentage of our effort, and often a lot greater than zero.

Building out the core of your application and righting the wrong assumptions made along the way sap time and energy from delivering working prototypes. And beyond development, you need a design and product team willing and able to rapidly context-switch between ideation and assimilation (processing feedback from clients and end-users).

This practice is not imbued in all teams, but all teams can learn it and several tools can help. If your team cannot iterate quickly or you cannot afford the tools which enable them to do so, RAD development may not be a suitable choice for your work.

Is RAD the same as agile?

A common question that pops up when talking about rapid application development is how it compares to agile software development.

Unfortunately, this comparison is challenging to draw.

RAD is a forebear of agile, but agile encompasses far more than a development model. It is more of a philosophy than a methodology.

In an attempt to show this, we have contrasted the core principles of each concept:

Learn more about different app development methodologies

Rapid application development tools

As you may now understand, rapid application development is more of a software development methodology rather than a specific language, tool, or interface. However, tools can help facilitate rapid prototyping, development, and feedback solicitation.

Design and prototyping tools

The products in this category help teams craft interactive designs at impressive speeds. And some tools on this list, like Webflow, allow designers to export the completed design as a functional cross-browser prototype.

User testing and feedback tools

As noted many times thus far, RAD methodology requires frequent feedback from clients and end-users. And in modern workflows, developers who work offsite prefer to solicit feedback remotely rather than book travel and accommodations each and every time they require input from clients.

Rapid application development platforms

If your team has strict technology requirements or a limited skill set, it’s simpler to stick with what they know. Often you cannot justify the cost of migrating technologies. But if you’re willing to consider a new approach to development, the tools and platforms in this category will accelerate your production cycle.

How OutSystems enables rapid application development

OutSystems is a high-performance low-code application platform.

That means our product goes beyond being a simple low-code tool for rapid application development by including hosting, dynamic scaling, release automation, performance monitoring, user management, version control, and much more.

At the core of our offering lies a powerful development environment.

Our platform combines low-code technology that automates and simplifies complexity, with the power and expressiveness of traditional development, thus enabling IT-adjacent roles to veteran IT professionals to build enterprise-grade web and mobile applications fast.

Rapid application development frequently asked questions