OutSystemsDev Zone

What Is Rapid Application Development?

Conceived in the 1980s, rapid application development, or RAD, was the first development methodology to challenge traditional waterfall development practices. Though often mistaken for a specific model, rapid application development is the idea that we benefit by treating our software projects like clay, rather than steel.

Software is a unique engineering structure because it is transient. With traditional engineering projects like bridge construction, engineers cannot begin to build a bridge then change their minds half way through the process—that’s pure chaos. But a bridge built in software? Engineers can change that every day. RAD takes advantage of this by emphasizing rapid prototyping over costly planning.

Brief History of rapid application development

Three quarters rapid application development timelineinto the previous century, humanity began to want software. Fulfilling this desire required developers. These software projects consumed months of laborious planning and even more in development—just like traditional engineering projects. Software architects worked with end-users to draft functional requirements, then spent countless hours defining them in spec sheets.

With specifications prepared, development began. Anywhere from months to years later, users got their first glimpse of the product they themselves requested. And if it failed to meet their expectations, the engineers would refactor—the costs of which were extraordinary.

This process, which began with the blackboard, moved to spec sheet, then to software, and terminated at the user, is known colloquially as the “waterfall” approach. It mirrored traditional engineering assignments that worked with immutable materials like wood, cement, and iron — once set and paid for, these resources were costly to alter.

In the 1980s, Barry Boehm, James Martin and others recognized the obvious: 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, RAD has evolved to take on other forms and acted as a precursor to agile.

Rapid Application Development vs Agile

Those who research development methodologies compare one framework to another. Most commonly, rapid application development is directly contrasted with agile. Unfortunately, this comparison is challenging to draw. RAD is a forbear of agile, but agile encompasses far more than a development model. It is more of a philosophy than methodology.

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

Agile PhilosophyRADExplanation
Customer satisfaction by early and continuous delivery of valuable softwareThis is a core principle of RAD
Welcome changing requirements, even in late developmentrapid application development check markAlso found in RAD practice
Working software is delivered frequently (weeks rather than months)rapid application development x markSpecific time-frames are not recommended by RAD though speed is clearly emphasized
Close, daily cooperation between business people and developersrapid application development x markNo direct equivalent in RAD, but feedback from end-users is critical to the RAD process
Projects are built around motivated individuals, who should be trustedrapid application development x markRAD has no opinion on the makeup of individual team members
Face-to-face conversation is the best form of communication (co-location)rapid application development x markRAD has no opinion regarding locality of team members
Working software is the primary measure of progressrapid application development check markRAD focuses on delivering working software as frequently as possible
Sustainable development, able to maintain a constant pacerapid application development x markRAD offers no opinion regarding the pace of development other than “rapid”
Continuous attention to technical excellence and good designrapid application development x markRAD principles focus on functionality and user satisfaction; quality of design and implementation are unnecessary, but ideal byproducts
Simplicity—the art of maximizing the amount of work not done—is essentialrapid application development x markHere again, RAD does not emphasize reduction of work, but proclaims that RAD projects will require less work in the long term
Best architectures, requirements and designs emerge from self-organizing teamsrapid application development x markRAD does not limit itself to a team structure
Regularly, the team reflects on how to become more effective and adjusts accordinglyrapid application development x markNot necessary or inherent to RAD practices

As you can see, agile took several steps beyond the scope of RAD. While agile dictates the ideal working environment (just shy of how many rubber ducks to keep on your desk), RAD focuses on how to build software products for your clients and end-users. Let’s take a closer look at what RAD entails.

Rapid Application Development Methodology

Though exact practices and tools vary between specific RAD methodologies, their underlying phases remain the same:

1. Define Requirements

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

Instead of committing to hard and fast specifications, 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 requirements (as in early stage prototyping).

This prototype may cut corners to reach a working state, and that’s acceptable. Most RAD approaches have a finalization stage at which developers pay down technical debts 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 may 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, maintainability, and a third word ending in ‘-ility.’ 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.

Both Boehm’s Spiral Model and James Martin’s RAD Model make use of these four steps to help development teams reduce risk and build excellent products. However, RAD has its drawbacks as well.

RAD: Advantages and Disadvantages

We’ve covered some advantages of RAD already, but let’s restate them and expand.

AdvantageDescription
SpeedIn the traditional waterfall approach, developers were unlikely to go on vacation after delivering the product. Clients would invariably request changes ranging from interface to functionality after first delivery.

With RAD, projects are more likely to finish on time and to the client’s satisfaction upon delivery.

CostIn rapid application development, developers build the exact systems the client requires, and nothing more. In waterfall, IT risks building and fleshing out complex feature sets that the client may choose to gut from the final product.

The time spent building zombie features can never be recovered, and that means the budget spent on them is lost. RAD reduces this risk and therefore reduces the cost.

Developer SatisfactionIn 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 RAD, 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.

 

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

DisadvantageDescription
ScaleA 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.

CommitmentIn 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 RAD, 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-FocusRAD 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 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.

 

With the pros and cons of rapid application development laid out, we can determine which types of projects benefit most from RAD, and which do not. If you need to build an internal business tool or even a customer-facing portal, like an app or website, RAD techniques will help your team deliver a better experience to your end-user.

However, if you are tasked with building mission-critical software (flight controls, implant firmware, etc.), a RAD approach is not only inappropriate, it may also be irresponsible. A pilot with a failing control module or a heart attack survivor with a malfunctioning pacemaker cannot provide prototype feedback from beyond the grave.

Tools for Rapid Application Development

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 design, 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.

ToolPrototypeRuns On
Origami StudioMobilemacOS
InVisionWeb, Mobile, WearablemacOS
WebflowWeb, MobileWeb
MockplusWeb, MobilemacOS, Windows
BalsamiqWeb, MobilemacOS, Windows
Adobe Experience DesignWeb, MobilemacOS, Windows
SketchWeb, MobilemacOS
JustInMindWeb, Mobile, WearablemacOS, Windows
Proto.ioWeb, Mobile, WearableWeb

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.

ToolPlatformsBest For
InVisionWeb, MobileClients
Red PenWeb, MobileClients
ConjureWebClients
Usability SciencesWeb, MobileEnd-Users
UserTestingWeb, MobileEnd-Users
ValidatelyWeb, Desktop, MobileEnd-Users
UserbrainWebEnd-Users

Development Tools

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 in this category will accelerate your production cycle.

Low-code tools, for example, bundle development elements (IDE, APIs, languages, framework, UI components, connectors, etc.) into a single coherent suite of tools for building applications visually, integrating them with the back-end, and then managing the app lifecycle.  No-code tools, by contrast, offer self-service application assembly for business users who are not developers.

ToolBuildsType
Salesforce AppCloudWeb, MobileNo-Code, Low-Code, SDK
Alpha SoftwareWindows, Web, MobileLow-Code
Visual LANSAWindows, Web, MobileLow-Code
Zoho CreatorWebLow-Code
AppianWeb, MobileLow-Code
WaveMakerWeb, MobileLow-Code
SpringDesktop, Web, MobileSDK
AppGyverMobileLow-Code
MendixWeb, MobileLow-Code
KonyWeb, MobileLow-Code, SDK
OutSystems (you are here!)Web, MobileLow-Code, SDK

How OutSystems Enables Rapid Application Development

We are an application platform as a service, or aPaaS. And that means our product goes beyond enabling rapid application development by including hosting, dynamic scaling, release automation, performance monitoring, user management, version control, and much more.

But at the core of our offering lies a powerful development environment. Our tool enables everyone from IT-adjacent roles to veteran IT professionals to build enterprise-grade web and mobile applications without code. And as with all low-code tools, seasoned developers may append our front-end and back-end implementations with their own scripts.

Ready to Develop 6x Faster?

View this two-minute video to see how it works. You can also schedule an online demo or even try OutSystems (it’s free).

About the author

Stanley Idesis

Stanley Idesis, a perennial American sweetheart, was on the direct path to become a mild-mannered power plant employee when he was bit by a radioactive programming spider! Overnight (and 6 years later), he's worked on dozens of native mobile applications. He applied those skills to mentoring students and writing courses for ed-tech.That was great and all, but then that blasted bug bit him again! Now he helps software organizations reach their developer audiences.

Comments

It is really nice and interesting blog, thanks for the sharing great article and you are explaining the RAD model very well. it is great content .

David

This is just so cool. Thanks for tips like this

[…] https://www.outsystems.com/blog/rapid-application-development.html […]

Thanks for the Rapid App Development explainer. Always good to see some light shined on this space.

If I may suggest another tool for your list:

Tool: Xojo (http://www.xojo.com)
Builds: Windows, macOS, Linux, Pi, web, mobile
Type: Low-code

Leave Your Comment