Rapid application development (RAD) describes a method of software development which heavily emphasizes rapid prototyping and iterative delivery. The RAD model is, therefore, a sharp alternative to the typical waterfall development model, which often focuses largely on planning and sequential design practices. First introduced in 1991 in James Martin's book by the same name, rapid application development has become one of the most popular and powerful development methods, which falls under the parental category of agile development techniques.
Some more specific takes on SDLC include:
Perhaps the biggest advantage of rapid application development is its inherent synergy with the requirements of the medium itself: software. Whereas other forms of creation, such as a towering skyscraper or a sleek new automobile, require meticulous planning and logical development, the very essence of software is both malleable and in constant evolution. Since code itself -- and by extension, the software which is powered by said code -- can be morphed quickly and easily during development, software is inherently adaptable, lending itself well to iteration and experimentation.
By utilizing a rapid application development method, designers and developers can aggressively utilize knowledge and discoveries gleaned during the development process itself to shape the design and or alter the software direction entirely.
Below we'll explore a few of the primary uses of rapid application development, in both historical and theoretical scenarios, as well as analyze both the pros and cons of this attractive method of software creation.
A Few RADical Steps
Getting started with rapid application development generally follows a cyclical process that includes four basic steps:
- Planning Requirements: During this initial stage designers, developers, and users come to a rough agreement on project scope and application requirements, so that future stages with prototyping can begin.
- User Design: User feedback is gathered with heavy emphasis on determining the system architecture. This allows initial modeling and prototypes to be created. This step is repeated as often as necessary as the project evolves.
- Rapid Construction: Once basic user and system design has begun, the construction phase is where most of the actual application coding, testing, and integration takes place. Along with User Design, the Rapid Construction phase is repeated as often as necessary, as new components are required or alterations are made to meet the needs of the project.
- Cutover: The final Cutover (or Transition) stage allows the development team time to move components to a live production environment, where any necessary full-scale testing or team training can take place.
User Interfacing, Early and Often
In the slow, methodical software development methods of olde, receiving useful and concrete user feedback has been inherently difficult, costly, and time consuming. Long meetings and phone calls, and even longer design docs, were a necessary evil to lay out even the most basic concrete plans of proper software design. With typical waterfall methods, rudimentary user feedback was often many months if not years in the future, after all planning and most development had taken place.
In stark contrast, one of the biggest benefits to rapid application development is the ability to both easily and frequently receive feedback from users who are directly interfacing with the application during development and prototyping. While this advantage is most readily visible within the UI/UX components of the system, iterative design intrinsically means user feedback can be at the forefront of the process.
A Prototype of Prototyping
While various forms of RAD emphasize slightly different concepts and design methodologies, a common inclusion in most RAD systems is the heavy use of prototyping. As an alternative to heavy-handed design specifications, the use of prototypes throughout the development cycle provides for a number of unique benefits:
- User Involvement: Unlike a traditional waterfall model, which requires the design team to discuss with users what features or implementations might be required and plan specifications around those ideas, a rapid prototype allows users to actually use the software and provide feedback on a live system, rather than attempting to provide abstract evaluations of a design document.
- Feasibility: Prototyping allows the development team to quickly evaluate the feasibility of a particularly complex or risky component right out of the gate. By recognizing and working on complicated systems early in the development lifecycle, the software will be more robust, less error-prone, and better structured for future design additions.
- Error Reduction & Debugging: With rapid prototype releases during a project, it is far more likely that errors will be both discovered (and subsequently squashed) far earlier in the development cycle than with a typical waterfall approach.
Pros of Rapid Application Development
While there are a number of benefits to using a rapid application development method, we've highlighted a handful of the most crucial when considering whether RAD is the right choice for your next project.
- Measurable Progress: With frequent iterations, components, and prototypes coming down the pipe, progress on the overall project, as well as lesser segments, can be easily measured and evaluated to maintain schedules and budgets.
- Quickly Generate Productive Code: As a larger percentage of active software developers move into multi-discipline roles (i.e. full-stack developers), a RAD methodology allows skilled team members to quickly produce prototypes and working code to illustrate examples that might otherwise take weeks or months to see the light of day using a slower development technique.
- Compartmentalization of System Components: Much in the same way that object-oriented programming practices keep objects and components quarantined from one another, RAD inherently has the same beneficial impact on the components generated during development. By forcing designers and developers to create components that are functional and independent on their own, to be used in an iterative release or prototype, each element within the overall software system is compartmentalized and therefore easily modified as the needs of the software evolve.
- Rapid, Constant User Feedback: As discussed above, obtaining relevant user feedback during development is invaluable. RAD methodologies allow for near-constant user interfacing and feedback through frequent iterations and prototype releases, giving the entire team priceless evaluation and criticism when it's needed most.
- Early Systems Integration: While most waterfall method software projects must, by their very nature, wait until the tail end of the lifecycle to begin integrations with other systems or services, a rapidly developed application becomes integrated almost immediately. By requiring early integrations within a prototype, a RAD system quickly identifies any errors or complications within integrations and forces immediate resolutions.
- Simple Adaptability: During development, software is a fairly malleable form. Since code can be changed that dramatically alters the entire system or generates new components, it is to the advantage of the development team to make use of this flexibility early and often, by iterating and prototyping potential concepts or ideas throughout development.
Cons of Rapid Application Development
No software development method is without fault and RAD is no different. While the benefits typically outweigh the disadvantages, we'll examine a few of the most likely roadblocks when implementing RAD into a new project.
- Requires Modular Systems: Since each component within the system should be iterable and testable on its own accord, the overall system design when using RAD requires that each component be modular, allowing elements to be swapped in and out or altered by a variety of team members.
- Difficulty Within Large-Scale Projects: While rapid application development methods lead to far greater flexibility during the design and development process, it will also tend to reduce control and restrictions. While this isn't inherently negative, properly managing this added flexibility and volatility within the scope of the whole project can be difficult for larger applications.
- Demands Frequent User Interfacing: Gaining user insight and feedback early and often is certainly a benefit from a design perspective, but this double-edged sword requires that the team be both willing and able to communicate with users on a much more frequent basis, in comparison to a typical waterfall development method.
- Depends Upon Skilled Developers: While many developers these days are multi-disciplined, it is worth noting that use of RAD techniques does require a greater overall skill across the development team, in order to quickly adapt as the system and components evolve.
