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. 1. A Brief History of RAD 2. RAD vs Agile 3. RAD Methodology 4. RAD Advantages and Disadvantages 5. Tools Which Enable RAD 6. How OutSystems Enables RAD https://www.outsystems.com/blog/rapid-application-development.html 2 Minute Demo: https://www.outsystems.com/videos/platform-overview

1. What Is Rapid Application
Development?
Stanley Idesis

2. An 80s Baby
2
Rapid application development, or
RAD, was among the first
development methods to challenge
traditional waterfall development
practices.
Though often mistaken for a specific
model, rapid application
development is the idea that we
benefit when we treat our software
projects like clay, rather than steel.

3. 3
“Software is clay, not steel”
- RAD

4. A Coded Bridge?
4
Software is a unique engineering
structure because it is highly
transient, unlike traditional
engineering projects.
Engineers cannot begin to build a
bridge and change the design
partway — that’s chaotic and costly.
But a bridge built in software?
Engineers can modify it daily.
RAD favors rapid
prototyping over costly
planning

5. 5
A Brief History of RAD

6. In the 1970s...
6
Humanity began to want software.
Software projects took months of
laborious planning and even more
time in development — just like
traditional engineering projects.
Software architects worked with
business and IT management to
draft functional requirements, then
spent countless hours defining
them in spec sheets.

7. With Specifications
Prepared...
7
Development began.
Anywhere from months to years
later, business and IT stakeholders
received their first glimpse of the
software product they requested.
And if it failed to meet their
expectations, the engineers would
refactor — the costs of which were
often extraordinary.

8. This Process...
8
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
physical materials like wood,
cement, and iron. Once set and
paid for, changing these resources
is a massive undertaking and
prohibitively expensive.

9. In the 1980s
9
Barry Boehm and James Martin
recognized the obvious: software is
not built of material resources.
They understood software for
what it was: infinitely and
affordably malleable.
Boehm and Martin took advantage
of software’s inherent pliability to
design brand new development
models: the Spiral Model and the
James Martin RAD model.

10. Both Models Evolved
1
To take on other forms which
ultimately acted as precursors to
the Agile Method.
Though often used
interchangeably, as if they mean
the same thing, RAD and agile are
quite different.
Snow leopards are agile,
magnificent creatures
Just FYI

11. 1
RAD vs Agile

12. RAD vs Agile
1
Rapid application development is
not only thought of as
interchangeable with agile, but also
frequently directly contrasted with
it. Unfortunately, it’s more
complicated than that.
RAD is a forbear of agile, but agile
encompasses far more than a
development model. It more
closely resembles a philosophy
than a methodology.
RAD is a methodology,
Agile is a philosophy

13. Agile Says...
1. “Customer
satisfaction by early
and continuous delivery
of valuable software.”
This is a core RAD principle.
1
...RAD Says

14. Agile Says...
2. “Welcome changing
requirements, even in
late development.”
Also found in RAD practice
1
...RAD Says

15. Agile Says...
3. “Working software is
delivered frequently
(weeks rather than
months).”
Specific time-frames are not
recommended by RAD,
though speed is clearly
emphasized.
1
...RAD Says

16. Agile Says...
4. “Close, daily
cooperation between
business people and
developers.”
No direct equivalent in RAD,
but feedback from end-
users is critical to the RAD
process.
1
...RAD Says

17. Agile Says...
5. “Projects are built
around motivated
individuals, who should
be trusted.”
RAD has no opinion on the
makeup of individual
team members.
1
...RAD Says

18. Agile Says...
6. “Face-to-face
conversation is the best
form of communication
(co-location).”
RAD has no opinion
regarding locality of team
members.
1
...RAD Says

19. Agile Says...
7. “Working software is
the primary measure of
progress.”
RAD focuses on delivering
working software as
frequently as possible.
1
...RAD Says

20. Agile Says...
8. “Sustainable
development, able to
maintain a constant
pace”
RAD offers no opinion
regarding the pace of
development other than
“rapid.”
2
...RAD Says

21. Agile Says...
9. “Continuous
attention to technical
excellence and good
design”
RAD principles focus on
functionality and user
satisfaction.
Quality of design and
implementation are
unnecessary, but ideal
byproducts.
2
...RAD Says

22. Agile Says...
10. “Simplicity—the art
of maximizing the
amount of work not
done—is essential”
Here again, RAD does not
emphasize reduction of
work, but proclaims that
RAD projects will require
less work in the long term.
2
...RAD Says

23. Agile Says...
11. “Best architectures,
requirements and
designs emerge from
self-organizing teams.”
RAD does not limit itself to a
team structure.
2
...RAD Says

24. Agile Says...
12. “Regularly, the team
reflects on how to
become more effective
and adjusts
accordingly.”
Not necessary or inherent
to RAD practices
2
...RAD Says

25. Agile...
2
Takes 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.
Two. In case the first
duck doesn’t “get you”

26. 2
RAD Methodology

27. 1. Define Requirements
2
A RAD project begins by defining a
loose set of requirements. And
they’re kept loose because RAD
permits requirements to change at
any point in the cycle.
The client provides their vision for
the product and comes to an
agreement with developers on the
initial requirements that satisfy
that vision.

28. 2. Prototype
2
Developers demonstrate
something 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.

29. 3. Incorporate Feedback
2
Developers present work to the
client or end-user. 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 which
seemed right on paper, made no
sense in practice.

30. 4. Finalize Product
3
Developers optimize their
implementation to improve
stability, maintainability and a third
word ending in ‘-ility.’
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.
But RAD has drawbacks as well...

31. 3
Advantages and
Disadvantages

32. Speed
3
ScaleVS
In the traditional waterfall
approach, clients invariably
requested changes after delivery.
With RAD, projects are more likely
to finish on time and to the client’s
satisfaction.
When a RAD project expands
beyond a single team, the
development cycle invariably
slows and muddles the project’s
direction.
Simply put, it’s difficult to keep a
large group of people on the
same page when your story
changes constantly.

33. Cost
3
CommitmentVS
In waterfall, IT risks building and
fleshing out complex feature sets
that clients may choose to gut
from the final product.
The time spent building zombie
features can never be recovered,
and that translates to sunk costs.
RAD developers build the exact
systems that clients require and
nothing more.
In waterfall, clients focused on
their primary tasks while
developers focused on theirs:
building the product.
In RAD, the prototyping cycles
require developers and clients
to commit to more frequent
meetings.

34. Developer Satisfaction
3
Interface-FocusVS
In waterfall, developers work in
silos. And when they finally present
their product to an unappreciative
client, their ego takes a hit.
In RAD, the client is there every
step of the way. This gives
developers the confidence that
upon delivery, their work is
appreciated.
RAD motivates developers to find
the perfect solution for clients.
The clients judge the solution
only by what they can interact
with—and often, that is merely a
facade.
As a consequence, some
developers forego best back-
end practices to accelerate
front-end development.

35. Good RAD Projects
3
● Internal employee tools
● Customer portals
● B2C applications
Not so good RAD projects…
● Mission-critical software
● Flight controls
● Pacemakers…
A team building a RAD
pacemaker will struggle
to collect user feedback
from the deceased.

36. 3
Tools Which Enable RAD

37. 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
completed designs as
functional cross-browser
prototypes.
3
Tool Prototype Requires
Origami Studio Mobile macOS
InVision Web, Mobile, Wearables macOS
Webflow Web, Mobile Web
Mockplus Web, Mobile macOS, Windows
Balsamiq Web, Mobile macOS, Windows
Adobe XD Web, Mobile macOS, Windows
Sketch Web, Mobile macOS
JustInMind Web, Mobile, Wearable macOS, Windows
Proto.io Web, Mobile, Wearable Web

38. User Testing and Feedback Tools
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
whenever they require
input from clients.
3
Tool Feedback For Best For
InVision Web, Mobile Clients
Red Pen Web, Mobile Clients
Conjure Web Clients
Usability Sciences Web, Mobile End-Users
UserTesting Web, Mobile End-Users
Validately Web End-Users
UserBrain Web End-Users

39. Rapid Development Tools
If your team has strict
technology requirements
or a limited skill set, it’s
easier to stick with what
they know. But if you’re
willing to consider a new
approach to
development, the tools
in this category will
accelerate your
production cycle.
3
Tool App Types Tool Type
Salesforce AppCloud Web, Mobile No-Code, Low-Code
Alpha Software Windows, Web, Mobile Low-Code
Zoho Creator Web Low-Code
Appian Web, Mobile Low-Code
WaveMaker Web, Mobile Low-Code
Spring Desktop, Web, Mobile SDK
Mendix Web, Mobile Low-Code
Kony Web, Mobile Low-Code, SDK
OutSystems Web, Mobile Low-Code, SDK

40. 4
How OutSystems Enables
RAD

41. Truly Integrated
Development
4
At the core of OutSystems lies a
powerful development
environment.
Our tool enables everyone from IT-
adjacent roles to veteran
developers to build enterprise-
grade web and mobile applications
without code.
Seasoned developers
can override behavior
with custom front and
backend scripts.

42. Beyond RAD
4
OutSystems goes past enabling
rapid application development by
including hosting, dynamic scaling,
release automation, performance
monitoring, user management,
version control, and much more on
top of a battle-tested cloud
platform.
Check? Nope. That
would be checkmate.

43. 4
▶ Two-minute demo ▶
Ready to develop 6x faster?