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
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:
? Speed: Thanks to the feedback from the prototype phase, there is a far greater likelihood that the product delivered will be acceptable to the client the first time.
? Cost: Developers build the exact systems the client requires and nothing more instead of building out complex features that may not make the final cut. The prototype stage of RAD eliminates this costly exercise.
? Developer Satisfaction: The client is there every step of the way as developers present their work frequently. Not only does the client become more confident, but the development team no longer feels divorced from those who will be using their software, resulting in opportunity for ownership and personal satisfaction.
The Drawbacks
RAD isn’t perfect. It has its own set of issues:
? Scale: While a small group of close-knit developers can easily handle changing requirements, it’s much harder to achieve this with a large, distributed team.
? Commitment: Clients must agree to frequent assessment and feedback meetings, which may seem daunting.
? Interface-focus: Clients judge the quality of the solution by what they can interact with, and often all they interact with is a fa?ade. Consequently, there’s a risk that some developers forgo best practices on the back-end to accelerate development of the front end.
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.
