RAD: Rapid Application Development
Posted January 28, 2022
Written by John Shea III, Xpanxion Technical Writer
There are three software development processes that people are familiar with: waterfall, agile, and DevOps. However, there is a lesser known fourth: Rapid Application Development (RAD). RAD is a method that foregoes the other three and tries to develop a functional prototype of the product (code or equipment) as fast as possible and not stopping until it’s perfect and ready to be immediately deployed. There can be many iterative cycles in this form of development toward perfection. In some programmer circles, for those not familiar with the process name, RAD was known as “winging it.” RAD is also called Rapid Application Building (RAB).
RAD’s goal is to maximize quality while minimizing cost. It revolves around the client and relies on the end user’s input in development.
The drawback to RAD is that it’s better with smaller, time-sensitive projects and teams with more experience. It’s not useful in larger products. There is less emphasis on planning. It relies on adaptation. Prototypes are used in addition or not at all with no design specifications.
When to use RAD?
An application RAD is well-suited for is the development of software for user interface requirements, such as graphical user interface builders. Another approach for rapid development is the previously mentioned agile method. There is also the Spiral method (the first for RAD models) for larger projects and products. Then there are the adaptive and unified methods. For now, we won’t discuss these but keep to the main RAD discussion.
Plan-based approaches such as waterfall try to rigidly define the requirements, solution, and how to implement it. The waterfall process tends to discourage changes. RAD understands software development is knowledge-intensive and provides a process that is flexible. This takes the opportunity of knowledge gained during a project to adapt or improve the solution.
In an instant gratification society, is RAD the answer to software development?
Not necessarily. It’s risky—developers have to change how they think. Non-functional requirements (criteria used to judge the system’s operation) are not immediately visible. It requires the time of scarce resources—the back-and-forth interactions of developers and users takes more time than the waterfall method where users define the requirements and go away. There is less control, and you could end up with prototypes of poor design. You can’t think BIG with RAD—you’re limited to small and medium size projects.
However, some have found RAD-developed projects to be of better quality—providing what the user exactly wants, while it’s risky there is better risk mitigation in the process, and more projects are completed on time and within the specified budget.
You be the judge. Or you can have Xpanxion help you with the dilemma of choosing which software development process to choose. Our teams of experts will assist you, be it custom application development like RAD or something else better suited for your software needs.
Xpanxion: How can we help solve your business problem?
About Xpanxion - Solving business problems with technology. We are software product engineering experts with over 20+ years of experience delivering the technologies, software architectures, processes and people critical to delivering success. As a trusted partner, we focus on business solutions and alliances that provide end-to-end value to solving our customer’s problems. We focus on providing best-in-class solutions by developing custom solutions with modern technologies or by delivering industry recognized off the shelf solutions.
Expertise Solutions and Alliances Platforms and Technologies Industries
Media Contact: firstname.lastname@example.org