Rapid Application Development (RAD)

Its every product managers’ desire to build a product right for change. A product of quality and void of feature creep. Desire to control the schedule and have a predictable shipping date.

But what actually happens when it comes to the real project. Time? Performance? Maintainability? Testing? My university professor back in engineering class one time introduced us to the ‘devil-quadrangle’; the constraints product managers struggle to balance with expertise and experience to get an ideal project condition.

But what is RAD?

Rapid application development means different things to different people.

To a hacker it means a 36 hour non-stop code stretch.

To an information engineer its a combination of case tools, intensive user involvement and tight time boxes.

To a product manager desperate to shorten a schedule. Its whatever practice highlighted in the most recent issue of business week.

All this are debatable and they seem to be okay to people in their respective spectrum. But from my software engineering perspective RAD is simply a descriptive phrase that contradicts traditional slow software development methodologies.

So how do we attain RAD?

To attain RAD we need to develop a culture of effective practice. This includes schedule oriented practices and an array of well thought strategies. We need to study the classical mistakes and avoid them at all costs, have solid fundamentals in development, develop good risk plans and have great people management skills. This i believe is an effective mix for RAD.

ref: Rapid Development~Taming Wild Software Schedules by Steve McConnell

Like what you read? Give Eric Ondenyi a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.