Published by Gbaf News
Posted on January 25, 2018
10 min readLast updated: January 21, 2026
Written by Nick Pike, Vice President, UK and Ireland, OutSystems
Although conceived back in the 1980s, the profile of rapid application development (RAD) is on the rise right now as a facilitating methodology for digital transformation in 2018 and beyond. As it is frequently confused with agile development and misconstrued as a model rather than a methodology, it’s time to understand exactly what rapid application development is, what it can achieve, and when it’s best to take a different approach.
The History
Rapid application development was the first engineering methodology to recognise the fundamental differences between software engineering and conventional engineering. Software is a unique engineering structure because it is transient. With traditional engineering projects like mechanical systems or big physical plants, engineers cannot begin to build them and then change their minds halfway through. But software? Engineers can change that every day. RAD takes advantage of this by emphasising rapid prototyping over costly planning.
In the late 1970s, projects followed the traditional engineering “waterfall” process, which is the same methodology applied to building bridges. Software architects worked with the stakeholders who wanted the software to draft functional requirements, then spent countless hours defining them in spec sheets. Only after all the specifications were prepared did development begin. Anywhere from months to years later, stakeholders (and users) got their first glimpse of their product. And if it failed to meet their expectations, the engineers would refactor—the costs of which were extraordinary.
In the 1980s, software engineers Barry Boehm and James Martin recognised the logical flaw in this approach. Unlike inflexible materials, software was infinitely changeable; any development methodology needed to take advantage of this fact. Thus, the principles of rapid application development were born.
Why RAD Is Not the Same as Agile
RAD and agile both emphasise early and continuous software delivery and welcome changing requirements even in late development. However, agile prescribes its methods and ideal working environments. RAD is far more flexible, emphasising quality outcomes over the exact way and timeframe in which they are delivered.
The RAD Methodology
The essence of RAD is its flexibility to adapt to changing customer vision throughout the development cycle. Its starts by defining a loose set of requirements, so developers get an idea of what the product needs to achieve. This couldn’t be further away from those detailed spec sheets of the past.
Developers then create a prototype that satisfies all or some of the requirements. This prototype may cut corners to reach a working state and that’s acceptable because any technical debt accrued will be paid down at a later stage. This prototype is presented to the client and feedback collected. At this point, clients may change their mind or discover that something that seemed right on paper makes no sense in practice. This kind of revision is an accepted part of the RAD approach and developers return to step two to revise the product.
If client feedback is entirely positive then developers can move to the ultimate step of finalising the product and it can be handed to the client with confidence that it meets their requirements.
The Advantages of RAD
So, what does RAD deliver in terms of benefits or value? The following list offers some answers:
The Drawbacks
RAD isn’t perfect. It has its own set of issues:
When RAD Works… and When It Doesn’t
With the pros and cons of RAD laid out, we can determine which projects benefit most from RAD, and which don’t. If you need to build an internal business tool or customer-facing portal like an app or website, RAD will help your team deliver an even better user experience.
However, if you are tasked with building flight controls, coronary implant firmware, or a massive finance and accounting system with layers of access and regulatory compliance, a RAD approach is not the best choice. All of these should not depend on prototypes that could fail at a terrible moment and cause countless amounts of harm and damage.
How OutSystems Enables Rapid Application Development
OutSystems goes beyond enabling rapid application development by including hosting, dynamic scaling, release automation, performance monitoring, user management, version control, and much more—all from a cloud. But at the core of it all is a powerful development environment that enables everyone from non IT roles to veteran IT professionals to build enterprise-grade web and mobile applications iteratively but without code and offer prototypes and proofs-of-concepts all along the development journey.
RAD has transformed the way we approach software development projects, enabling businesses to keep pace with the ever-shortening innovation and disruption cycle. Powered by a raft of tools that facilitate the swift-prototype, iterative approach, including low-code platforms such as our own, the RAD methodology is a vital tool in the arsenal of today’s dynamic organisations.
Written by Nick Pike, Vice President, UK and Ireland, OutSystems
Although conceived back in the 1980s, the profile of rapid application development (RAD) is on the rise right now as a facilitating methodology for digital transformation in 2018 and beyond. As it is frequently confused with agile development and misconstrued as a model rather than a methodology, it’s time to understand exactly what rapid application development is, what it can achieve, and when it’s best to take a different approach.
The History
Rapid application development was the first engineering methodology to recognise the fundamental differences between software engineering and conventional engineering. Software is a unique engineering structure because it is transient. With traditional engineering projects like mechanical systems or big physical plants, engineers cannot begin to build them and then change their minds halfway through. But software? Engineers can change that every day. RAD takes advantage of this by emphasising rapid prototyping over costly planning.
In the late 1970s, projects followed the traditional engineering “waterfall” process, which is the same methodology applied to building bridges. Software architects worked with the stakeholders who wanted the software to draft functional requirements, then spent countless hours defining them in spec sheets. Only after all the specifications were prepared did development begin. Anywhere from months to years later, stakeholders (and users) got their first glimpse of their product. And if it failed to meet their expectations, the engineers would refactor—the costs of which were extraordinary.
In the 1980s, software engineers Barry Boehm and James Martin recognised the logical flaw in this approach. Unlike inflexible materials, software was infinitely changeable; any development methodology needed to take advantage of this fact. Thus, the principles of rapid application development were born.
Why RAD Is Not the Same as Agile
RAD and agile both emphasise early and continuous software delivery and welcome changing requirements even in late development. However, agile prescribes its methods and ideal working environments. RAD is far more flexible, emphasising quality outcomes over the exact way and timeframe in which they are delivered.
The RAD Methodology
The essence of RAD is its flexibility to adapt to changing customer vision throughout the development cycle. Its starts by defining a loose set of requirements, so developers get an idea of what the product needs to achieve. This couldn’t be further away from those detailed spec sheets of the past.
Developers then create a prototype that satisfies all or some of the requirements. This prototype may cut corners to reach a working state and that’s acceptable because any technical debt accrued will be paid down at a later stage. This prototype is presented to the client and feedback collected. At this point, clients may change their mind or discover that something that seemed right on paper makes no sense in practice. This kind of revision is an accepted part of the RAD approach and developers return to step two to revise the product.
If client feedback is entirely positive then developers can move to the ultimate step of finalising the product and it can be handed to the client with confidence that it meets their requirements.
The Advantages of RAD
So, what does RAD deliver in terms of benefits or value? The following list offers some answers:
The Drawbacks
RAD isn’t perfect. It has its own set of issues:
When RAD Works… and When It Doesn’t
With the pros and cons of RAD laid out, we can determine which projects benefit most from RAD, and which don’t. If you need to build an internal business tool or customer-facing portal like an app or website, RAD will help your team deliver an even better user experience.
However, if you are tasked with building flight controls, coronary implant firmware, or a massive finance and accounting system with layers of access and regulatory compliance, a RAD approach is not the best choice. All of these should not depend on prototypes that could fail at a terrible moment and cause countless amounts of harm and damage.
How OutSystems Enables Rapid Application Development
OutSystems goes beyond enabling rapid application development by including hosting, dynamic scaling, release automation, performance monitoring, user management, version control, and much more—all from a cloud. But at the core of it all is a powerful development environment that enables everyone from non IT roles to veteran IT professionals to build enterprise-grade web and mobile applications iteratively but without code and offer prototypes and proofs-of-concepts all along the development journey.
RAD has transformed the way we approach software development projects, enabling businesses to keep pace with the ever-shortening innovation and disruption cycle. Powered by a raft of tools that facilitate the swift-prototype, iterative approach, including low-code platforms such as our own, the RAD methodology is a vital tool in the arsenal of today’s dynamic organisations.
Explore more articles in the Technology category
