Rapid Application Development: What It Is and What's Next

Rapid application development (RAD) has come a long way. When James Martin first developed this software development method back in 1991, he did it in response to the prevailing paradigm for software development: waterfall.

The waterfall methodology follows a logical sequence of steps throughout the software development life cycle (SDLC). These incremental steps resemble cascading water until they eventually reach the endpoint and produce a software product.

The main issue with waterfall and similar philosophies is that they were influenced by traditional engineering methods for creating things like bridges and buildings. They treat software development as a linear progression. Requirements influence the design of the solution, which in turn influences the progress of development.

But software development is an entirely different beast. Your team can take the knowledge they’ve gained from the development process and feed it back into both the requirements and the solution design.

What Is Rapid Application Development?

At its core, RAD recognizes the back-and-forth nature of software development: the process influences the planning, and the planning influences the process. When you understand this unique feature of software development, you’ll appreciate these five defining characteristics of RAD.

RAD Deemphasizes Strict Planning

Just like in the waterfall model, planning and requirements gathering are key to the RAD process. You won’t abandon these stages entirely. In fact, you’ll use them in the start of the RAD process, as seen in James Martin’s model:

However, you shouldn’t dogmatically adhere to plans formed at the beginning of a project. As a team leader, you know the plans you make during the initial stages happen when you know the least about the project. Therefore, those plans have the highest amount of uncertainty. Indeed, you should have a healthy dose of skepticism about the accuracy and suitability of your initial plans.

But avoid using this fact as an excuse to do zero planning. You must find the right balance. You need to know when to follow your plans strictly and when to tweak them. And there may be times when you’ll need to upend your plans. That’s especially true when you uncover new information during development that breaks the fundamental assumptions in your plans.

One quote I use to help me find the right balance comes from General Dwight D. Eisenhower, a successful leader in a different domain:

“In preparing for battle I have always found that plans are useless, but planning is indispensable.”

Eisenhower would have made a fine project manager.

RAD Involves Users Early in the Design Phase

RAD emphasizes working software and user feedback. Once the requirements planning phase is complete, RAD brings in users early in the design phase. Users interact with analysts to produce models and prototypes that capture the expected inputs and outputs of all the desired system processes.

This is the part most people associate with RAD. They assume it’s called rapid because you build prototypes early in the SDLC compared with the traditional waterfall method. But actually, the point of creating prototypes is so that analysts and users can test their combined understanding of the desired outcomes.

RAD Doesn’t Get Overly Attached to Prototypes

Without a prototype to push back against, user feedback can feel ephemeral and vague. But one potential pitfall in RAD is becoming overly invested with initial prototypes. Remember, your team’s knowledge is at its lowest at the start of the project. So after you receive user feedback, don’t force the development team to continue building on these first prototypes. In fact, you may have to persuade them to abandon the early models and start from scratch.

If your team invests a considerable amount of time and effort building early prototypes, they may become too attached. That in turn will increase the risk of failure for your team. After all, they haven’t sufficiently explored the problem space with the users’ help.

As a yardstick, try this. If your team isn’t willing to walk away from any prototype at this stage, they’re too attached. One way to mitigate this mistake is to push your team toward building multiple low-fidelity prototypes instead.

And it’s not just the developers. Users might get too attached as well. Educate your users so they know that early prototypes are only for generating useful feedback and uncovering the “unknown unknowns.” They don’t represent what the final product will become.

RAD Uncovers Any “Unknown Unknowns”

How do you know you’re finished with the user design phase? The answer is when your team has gathered sufficient user feedback to make major changes to the requirements. Or to quote Colin Powell, another famous U.S. general,

“No battle plan survives contact with the enemy.”

In other words, when you do RAD correctly, your initial requirements plan won’t survive the first round of user feedback unscathed.

Hopefully your team will uncover at least one or two major “unknown unknowns” that you weren’t even aware you didn’t know. This step is the best way to de-risk your project. And uncovering them before you’ve invested any heavy engineering efforts and budget to develop the initial version of the product should help you avoid costly mistakes later on.

RAD Constructs With User Feedback and Cutover

By now, your team should have settled on a single direction for the project. And while the user design phase may have ended, the user feedback continues—although it’s more tapered in volume and more targeted toward specific outcomes. To use agile terms, the first two phases (requirements planning and user design) are about discovery. Now your team will enter the delivery phase.

You’re building toward what should be an initial release. And you’re tapping into your users to give more specific feedback on the features as they’re being developed. This means the bulk of the communication will shift from being mostly between the users and the analysts to being between the developers and the users. That’s because if you do the first two phases correctly, then your developers should be on the same wavelength as your users.

The end stage is the cutover phase, where one-off efforts such as data migration, changeover, testing, and user training take place. This phase resembles the traditional waterfall approach the most. Therefore, I won’t spend time talking about cutover; it’s not what makes RAD so much better than waterfall. Rather, keys to RAD’s success are bringing forward the steps to uncover any unknowns and de-risking the project early on.

What’s Next?

Today’s software development is getting more complex, and the complexity is accelerating. Applications today are moving towards the distributed systems model. And businesses themselves are increasingly customer focused.

Software development cannot be complex for its own sake; it must be tied to the value generated for its customers. As such, methodologies like RAD that are primarily concerned with delivering software may not be enough to ensure companies withstand the fierce competition.

Lean and agile methodologies continue to be useful. But as IT leaders, we need to also consider the impact and value delivered to end customers. Lean and agile methodologies that focus on delivering value will be the natural next step in the evolution of software development.

And What's Next for You?

Now that I've written extensively about the RAD development cycle, you should have a better idea about what it entails and how it can benefit your team. RAD is grouped within a cluster of similar approaches to software development that are widely known as agile methodology. Agile is now a dominant paradigm.

What gets measured gets done, as the saying goes. So in the case of software development, the best way to measure your team's agility is to measure the releases. Building successful software is like being pregnant: you either are or you aren't. There's nothing in between. It doesn't matter how successful your team may be during the early stages of RAD. If you don't release software fast and frequently and if it doesn't make an impact on its users, then your team has failed to be agile.

As a natural next step, I urge you to learn more about the agile paradigm. You should also understand how to measure your team's agility through its software releases. Because at the end of the day, releases never lie. The more impactful and the more frequent your releases are, the more agile your team.