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.
Why Do We Need A New Paradigm?
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.
- Better software that is driven by prototypes that bring requirements to life and encourage meaningful feedback from customers.
- Speedier time to market as designers and developers focus on building software over waiting on checkpoints.
- Lower cost of development thanks to rapid feedback loops that identify mistakes earlier in the process and enable quicker fixes.
- More meaningful iterations, where unknowns are tackled earlier, and learning can be better leveraged.
The Big Shift: Updating People, Processes, And Priorities
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.
Same And Different: RAD And Other Non-Waterfall SDLC Models
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.
Likewise, RAD is not:
- JAD or joint application development. JAD refers to collaborative design between users and developers, making it a piece part, not parallel, of RAD.
- DSDM, or dynamic systems development method. This was an early precursor to Agile, a first step towards bringing some repeatable, scalable processes to the RAD principles we’ll look at next. A lot of DSDM thinking can be found at work in today’s Agile software shops.
Principles In Action: What RAD Wants (And How It Works)
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.
The Philosophy: Fast, Flexible, Open-ended
- Requirements are gathered but are considered a moving target across the lifecycle.
- Software is designed and built in modular components that are continuously tested against requirements in loops, not sequential phases.
- Once the software has reached sufficient maturity, it can be cutover/released.
The Target: The Prototype
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.
Prototype vs. MVP
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.
The Phases: A Closer Look at Process
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.
Step By Step: A Deeper Dive On Rapid Application Phases
- Requirements is a highly collaborative and communicative cross-functional conversation where the customer and technical requirements are captured with as much detail as possible. These include, but are not be limited to:
- Business needs modeling – process inputs and outputs, integration points, and final productivity measures
- Data modeling – data inputs and outputs, sources and systems involved in gathering and analysis
- Technical requirements – where and how the application will run, including both user OS and backend infrastructure
- Interface requirements – what the application will look like
These requirements are captured once, but the iterative approach of RAD means they may change over time.
- Prototyping is a combination of the traditional design and feedback phases. We’ve already read about prototypes as an object, and they remain a key differentiator vs. other SDLCs. This phase is mainly multiple loops of:
- Designing the initial prototype
- Testing the prototype vs. user and technical requirements
- Refining the prototyping until it reaches a suitable end-state
Once the MVP goals have been reached, the phase is complete.
- Construction is where the prototype turns into a full-fledged application. This is where developers focus on backend requirements and default details like security and manageability.
- Cutover/Implementation occurs when the SDLC is complete, and the software is ready to be turned over to customers for implementation.
- Finally, maintenance becomes another ongoing loop, where updates and fixes are applied, regular releases are scheduled, and functionality is expanded as required.
The Benefits
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?
Prioritizing Prototypes Over Process Produces Better Software Faster
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.
Goal: Collaboration and Cross-functional Expertise Reduce Costs and Complexity
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?
Making RAD Work: What It Takes To Be Successful
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.
A Collaborative Culture
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.
A Cross-Functional Perspective
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.
Ongoing Customer Access
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?
Pieces and Platforms
Embracing RAD doesn’t require selecting a specific development platform. Ultimately your tools will need to match the complexity of what you’re building.
Prototypes
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.
Construction
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
The Flip Side: Where RAD Doesn’t Win
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?
- Culture – RAD development also requires new ways of managing projects and priorities. In organizations that don’t adapt well to these changes, RAD gets less effective.
- Complexity - RAD is best suited to applications where feature sets are most modular and straightforward. Security and scalability challenges can make RAD less useful, and high technical risk will usually require a slower process.
- Customers – RAD excels where customers can be engaged early and often. Otherwise, meaningful iteration gets much harder, and a shift to RAD is less meaningful.
- Cash - working fast means a high burn rate on developer hours. Even if money is saved over the entire SDLC, costs can be a barrier to RAD adoption.
Getting Started
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.
Select for Modularity
Find a project that can be broken into small, bite-sized pieces. These offer ideal opportunities for test drive RAD.
Build Stakeholder Consensus
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.
Assess Cross-Functional Strengths
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.
Revisit Your Management Philosophies
Just as it requires new ways of building software, rapid application development also requires a different project management strategy.
Let Kintone Help
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.
About the Author
