Whether it’s a consumer-facing app or an internal business tool, software development is guided by two questions: what and how. Choosing what to build should be driven by product and market strategy specifics. The decision on how to build should be determined by looking at best practices. Today, this often means leaving traditional software development models behind in favor of rapid application development (RAD).
More than a single process or platform (we’ll look at RAD vs. Agile in a bit), rapid application development (RAD) represents a fundamental shift in how software is designed, built, and delivered. Beyond speeding time to market, reducing costs, and boosting quality, RAD is also conceptually aligned with other IT trends that favor agility, iteration, and re-use. It’s part of a new mindset that helps organizations transform how they bring value to the market and their business model.
Traditional software development processes tend to follow a linear waterfall approach, where each phase must be completed before the next is started. In between each phase are hand-offs between teams. While each organization approaches the software development lifecycle (SDLC) differently, they typically start with requirements and end with delivery to customers.
Waterfall development was foundational to the digital age. However, as with any other discipline, new best practices have emerged. Agile is one expression of RAD, but there are others. They all offer critical advantages to both organizations and their customers.
The waterfall approach was introduced in the early 1970s. RAD was first proposed in James Martin’s 1991 book of the same name. Martin believed that since so much typically changed during a lengthy software development process, a rigid waterfall approach that couldn’t incorporate new ‘facts on the ground’ was doomed to fail. The result would always be a product with lower quality, at a higher cost, that ultimately took longer to deliver.
Martin’s model roughly followed the same process as waterfall—requirements, design, build, cutover—with two distinct differences. First, the process became loop-driven, not linear. Once requirements were understood, designing and building were done simultaneously using a prototype, enabling feedback from building to impact design and vice versa.
Secondly, Martin saw this continuous feedback as absolutely essential. Waterfall development interacts with users when requirements are documented and then again when the software is delivered. RAD keeps users involved throughout the process, reacting to prototypes with feedback that immediately impacts development.
You may not have heard of RAD, but you’ve probably heard of Agile. While RAD pre-dates formalized Agile thinking by about a decade, it’s become the most popular expression of Martin’s ideas.
We’ll look at some key differentiators between RAD and Agile in a bit, but it’s important to understand the terms are not interchangeable.
When introduced, the premise of RAD was simple. In order to get better software, you have to build it differently. Breaking away from waterfall habits was the first step. Early RAD iterations were not particularly disciplined, but Agile and other methodologies have filled in some of those details since. Martin’s basic thinking has remained in force throughout.
Fundamental to RAD (and agile) is the idea of a prototype. A prototype is a working version of software that reflects at least some of the basic user requirements. These are usually gathered into a formal product requirement document (PRD) or similar deliverable.
The idea of the first prototype isn’t to make it perfect, but to get it finished. This allows the teams to collaborate on something substantial, rather than continuing to debate abstract implications and expectations. Prototypes typically move from low to high fidelity. As you can guess, low fidelity means that basic functionality is achieved, but the prototype won’t look or feel like the finished product. High fidelity prototypes are closer to requirements in both form and function. Most teams move from the former to the latter.
If you’re familiar with Agile, you’ve probably read about Minimum Viable Products (or MVP). The already vague term is used differently by different stakeholders. It primarily refers to an agreed-upon “first draft” of an application or component. It doesn’t necessarily mean the product will be ready for market, but rather that it captures enough of the requirements that it can be used as a prototype for iteration.
One way of looking at an MVP is that it allows the team to complete a first learning and exploration loop. With the prototype in place, design and development iterations can proceed, and those learning loops will build on each other through the SDLC.
Remember that the SDLC and RAD processes are made up of similar component phases. The real difference lies in the pace of work and the ability to run pieces of the process in parallel. Martin’s early vision collapsed some of the waterfall process to simplify it, but the key functions are all there.
These requirements are captured once, but the iterative approach of RAD means they may change over time.
Once the MVP goals have been reached, the phase is complete.
Now that we can see how the phases work together, it’s time to see why, in this case, different is better. How does RAD uniquely enable benefits for both users and software makers?
Unlike waterfall checkpoints, where stakeholders must wait on hand-offs from a previous phase before they can begin work, RAD emphasizes working continuously in parallel. Rather than gathering requirements once and then waiting for a finished product to find out if those requirements are met, rapid development moves as quickly as possible to design and build.
Once a prototype is built, stakeholders can review it, users especially. It can also be tested for feature set, integration, security, and scalability concerns. While this initial prototype may be a long way from being release-ready, it’s still a better start than a long list of requirements. Why?
Stakeholder requirements are often gathered in a vacuum, where they remain an abstract list of wants or wishes. Users engage better with something closer to a final product, where they can walk-through real-world workflows. This interaction can generate useful feedback in real time.
On the developer side, moving quickly to prototyping allows unknown unknowns to emerge earlier, giving teams more time to address issues, especially integration. Components can be built and tested together sooner, leading to quicker mitigation of errors that wouldn’t show up until much later in a traditional waterfall SDLC.
RAD is also a better way to leverage the cross-functional expertise of your development team. Rather than working deep in siloes and only interacting during a hand-off, teams can work collaboratively to design, build, and fix code inside a working prototype. It can also lead to identifying opportunities for re-using code and objects across the application since developers are building pieces of the system independently but simultaneously.
Rapid development also simplifies software testing. In addition to the informal testing that happens as prototypes are evaluated and updated, unit, and user stories (for Agile development environments) can be managed in continuous iterations. It also means user acceptance testing is ongoing, eliminating unpleasant surprises that could await the end of waterfall development.
RECOMMENDED: Low Code vs. Customized Software: What's the Difference?
We already know that rapid application development is not a prescribed list of specific tools and processes. Agile and other adaptive approaches to software development have helped fill in some of the details over time, providing high-level RAD ideals with some foundational best practices that can be shared and scaled.
However, regardless of which rapid path is right for your software needs, embracing RAD at a high level still requires distinct cultural and strategic choices. Without consensus around these decisions, it’ll be much harder to unlock the full potential of iterative, adaptive software design, and development.
Regardless of the size of the development shop, collaboration and communication are critical to making RAD work. Teams will be working fast and furiously together in the face of constant change, so they need to be well-versed in staying cooperative and communicative throughout the process.
Collaboration doesn’t have to mean proximity. Even distributed organizations can make rapid application development work if the foundation is set correctly. Team members simply have to be available to others across a core set of working hours.
Building software as objects or modules means maintaining a big-picture perspective even as your teams deal with granular technical and business requirements. Rapid development succeeds best where cross-functional expertise exists, but that doesn’t mean every team member has to be able to build software, databases, and create UI wireframes.
It does mean that there needs to be project management above the silo level, ensuring teams are working in the same direction, even as they work at different ends of a particular application. This is especially true during the requirements gathering process, where it’s critical to understand the implications up and down the software stack.
Finally, rapid development works best when you have ongoing access to customers or their stakeholders throughout the process. With traditional waterfall development, customers signoff on requirements and then come back for UAT. In a rapid application environment, the customer engaged with the entire process.
Customers want a high-quality product at lowest cost. While the RAD approach requires more of their time, the investment pays off through lower costs and faster delivery times. Ultimately, they get a product that closely meets their needs. What customer doesn’t want that?
Embracing RAD doesn’t require selecting a specific development platform. Ultimately your tools will need to match the complexity of what you’re building.
During this stage, prototyping tools can be useful for quickly managing details such as user interface, although you’ll still need those talents during the construction phase.
There are a lot of excellent object-oriented application building platforms on the market that allow you to build basic SaaS applications. They don’t have the depth of flexibility as some prototyping tools, but for basic workflow digitalization, they can work well. Depending on the depth of application complexity, these can get you started.
ALSO READ: Low-Code: It's Not a Question of What Can Be Done but What Can't Be Done With It
As important as it is to understand where RAD excels, it’s also important to know where it might not be the right choice. Whether it’s technical considerations or internal cultural constraints, some projects aren’t a good fit. Why?
If you’re considering switching gears from traditional waterfall development to RAD, it’s important to find a suitable pilot project. This lets your teams get used to new processes and priorities without injecting additional risk into already uncertain software development processes.
Find a project that can be broken into small, bite-sized pieces. These offer ideal opportunities for test drive RAD.
Make sure your teams are ready for a new way of working. This also includes your customers, internal or external, because their participation is critical.
RAD won’t succeed if you’re working inside traditional siloes. You need to make sure you can balance a big-picture perspective alongside specialized skills.
Just as it requires new ways of building software, rapid application development also requires a different project management strategy.
Moving from traditional software development to a rapid, iterative approach is a big step. Before you make it, our rapid application deployment experts can help you evaluate your choices to ensure your next step makes sense. We’ve helped organizations of all shapes and sizes transform how they deliver value – let’s talk about how we can do the same for you.