Rapid Application Development (RAD) was first coined by James Martin in 1991 in an effort to develop a new approach for software development. The current standard at the time—the Waterfall methodology—focused heavily on planning and following a series of steps in the development process.The development process went through each step in sequential order, with one step being completed before the next one was started.
Requirements for an application were identified and used to design the system. Then, development began. Upon completion, the application was tested for security issues and other bugs. After all of this was finished, the application was deployed and maintained.
The most significant downside to this approach is that user feedback is not incorporated until the very end of the design process. RAD was conceived to address the shortcomings of Waterfall development, placing significant focus on the user. This approach provides many benefits to the software development process.
RAD is still around, but we tend to think of it as a part of Agile development. A closer look at the RAD methodology and how it fits in with Agile helps us identify when it is the right approach to use, and how it can save you time and money in the application design and development process.
What is Rapid Application Development and how does it fit with the Agile methodology?
Rapid Application Development is a software development philosophy that places emphasis on rapid prototyping, user feedback, and iterative design. The underlying concept of RAD is the belief that users know what they want when they see it.
The sooner you show them something and actually put it into their hands, the sooner you can get feedback on it and make adjustments.
RAD is a natural part of the larger Agile methodology that is popular in today’s software and application universe. The Agile approach goes well beyond RAD in its applications, but it shares the same emphasis on the importance of development being an iterative process with a primary focus on the user experience.
Teams adhering to an Agile approach implement RAD only when it makes sense for the project, keeping the process Agile and efficient.
How to implement the Rapid Application Development methodology
There are four steps to the RAD methodology:
Step 1: Define the requirements
First and foremost, you need to know what you are building and why you are building it. What purpose does your application serve? Why will people want to use it and keep using it? A clearly stated purpose allows you to identify the necessary systems, resources, and budget requirements for the project.
Step 2: Rapid prototyping
As its name implies, prototyping must be done quickly. The goal is to get a functioning prototype into the hands of users as quickly as possible to gather feedback.
Do not sacrifice functionality over speed. Your initial prototype does not need all of the bells and whistles you are considering, but it does need to provide basic functionality so users can interact with it and offer valid feedback.
Rapid prototyping identifies errors and poor design earlier in the development process. There are some tools that can assist you in your rapid prototyping efforts:
- InVision has excellent apps for design-only prototyping.
- Sketch App Sources is a great resource for wireframing.
Step 3: Obtain user feedback
This is the gold mine of RAD. As users interact with your prototypes, the information they share about their user experience is gathered and analyzed to further improve the application.
Unnecessary features can be removed, buttons can be redesigned or relocated, and new requested features can be addressed. We find that many times we cannot guess how users will like an application until they are actually using it. Real feedback is the best way to improve an application.
Step 4: Repeat
Immediately go back to steps two and three. Incorporate user feedback into a new prototype and put it in front of users again. Continue this process until you have a version ready for full-scale deployment.
Even after deployment, the process of incorporating user feedback to improve the application should continue throughout the application lifecycle. An Agile Product Owner plays a pivotal role in keeping the focus on the user. For more information on how an Agile Product Owner contributes to success, consult our blog.
You can also work with a company that specializes in software application development. An expert team should have deep knowledge of the RAD methodology and experience in rapid web, mobile, and desktop application development. The team should also understand the importance of user feedback.
The benefits of RAD: Time and money
- Save time—A functioning product is developed quickly with the RAD approach, getting your product out to market faster. This emphasis on speed eliminates wasted time in the design and development process and keeps your application competitive.
- Save money—RAD puts your application in the hands of users early in the development process, before you have added every feature under the sun. You can identify areas that need improvement and unnecessary features before you spend money building your entire vision for the application. Features you thought were essential may turn out to be completely unnecessary once a user gets their hands on the app. Conversely, a new functionality that may not even be on your radar may be identified. Budget can be properly allocated so you develop the best application without wasting money (or losing sales) due to poor design and functionality.
- Build a better application—The iterative process of RAD and its focus on incorporating real user feedback produces a better end product, one that users will want to download and use. You can be confident in your application because you have been checking in with real users consistently throughout the design and development process, making sure the app does, in fact, deliver on its intended purpose. RAD supports the development of what we like to call the new MVP, a Minimum Valuable Product. This is similar to the traditional Minimum Viable Product that Agile supports, but a Minimum Valuable Product places focus on releasing a product that is commercially valuable as opposed to merely functional. More information on a Minimum Valuable Product can be found here.
- Make large projects more manageable—The RAD methodology allows your design and development teams to break large projects up into smaller, more manageable tasks. These small wins keep the team motivated and keep the larger project on target for completion.
- Measure progress simply—The iterative process and rapid prototyping of RAD gives your team concrete, short-term goals that can easily be measured. Projects can be tracked against a timeline, making them easier to keep on schedule.
- Identify integration issues early—The rapid prototyping of RAD allows your team to test how well your application integrates with other systems or services, such as API integration. Any integration issues can be resolved earlier in the development process.
- Incorporate changes easily—Flexibility and change is the crux of RAD. The whole idea of the iterative approach makes incorporating changes to your code easier.
When to implement RAD
As a general rule, the RAD methodology is the best choice when:
- Your application needs to be designed and developed quickly.
- The application is going to end up in the hands of users in front of a screen.
If the primary purpose of your application is to serve a user sitting in front of any type of screen (be it a desktop, laptop, smartphone, or kiosk), getting user feedback early in the development process is ideal.
But RAD is not always the right choice for a project. It does have its disadvantages:
- Additional resources are required for feedback—Gathering constant user feedback requires time and communication. The proper channels need to be established to make sure feedback is gathered in an organized manner, and can easily be shared with the development team. Poor coordination and communication creates challenges in the RAD process, and can hold up development. For RAD to work, you need to have a formal process in place, one specifically designed to incorporate feedback, communication, development, and design into separate (but equally important) tasks and responsibilities. And they must all function in concert with one another.
- Demands a higher skill level—The flexibility and adaptability of RAD requires a certain level of skill among developers, as your application is continually evolving.
RAD is not ideal for certain types of software applications:
- Highly technical applications—When there is a high level of technical risk with your application, the Waterfall approach is often the better choice. You want to make sure all steps and processes are well-documented and performed in a methodical manner to reduce the risk of errors. Speed is not the primary concern in these situations.
- Not designed for end users—If your application is not going to end up in the hands of users, RAD is not the best approach. If, for example, you’re building an application for a pacemaker, the iterative process is not ideal. You want to make sure that application is at its best before using it.
Rapid Application Development is an effective development philosophy for applications designed for end users—humans who will be looking at a screen and interacting with your app. In these instances, the RAD approach creates a better end product that is delivered to market faster, while also saving money on unnecessary development costs. Your application stays competitive in the marketplace, generating more revenue while building a loyal user base.
