Sponsored By Aspose - File Format APIs for .NET

Aspose are the market leader of .NET APIs for file business formats – natively work with DOCX, XLSX, PPT, PDF, MSG, MPP, images formats and many more!

RAD in the Time Of Agile Development

This blog post is a direct copy of my editorial in the June/July 2006 issue of CoDe Magazine (http://www.code-magazine.com/subscribe/rodman).


 I wanted to throw this up here and see what you all think. Am I all wet or are the similarities between RAD and Agile really there ?


 


Rapid Application Development (RAD) software development techniques have become an integral part of day-to-day software development in the past four years. This is the same RAD that James Martin described in the 80’s and published in his book, Information Engineering: Introduction, in 1991 (15 years ago). WikiPedia (www.wikipedia.com) states that “RAD was a response to the non-agile development technologies developed in the 1970’s known as the waterfall method.”


 


The waterfall method failed because it had long lag times between the system request and the delivery of the final product. In many cases, software created using the waterfall method didn’t meet the requirements of the user or the business had changed so much that no one needed the software by the time it was delivered.


 


Today RAD has been embodied in a number of methodologies including Agile Development, Extreme Programming, and Test Driven Development. While they all have different names, they all share a common theme:


 


Deliver software into the hands of users as soon as possible.


 


These techniques take into account that software is not perfect nor is it EVER 100% complete. Their major advantage is that they deliver results rapidly which is what customers/users demand.


 


In the last few months I have personally experienced/discovered a number of successful uses for RAD/agile development techniques.


 


This month a team I worked on successfully used RAD/agile development techniques to deliver a project for a client. At the request of the CEO and VP of Software Development, we started and completed a system for capturing employment applications on the Internet. This application has upwards of 20+ Web pages for capturing, validating, administrating, and printing employment applications. And the application did exactly what the users wanted.


 


I also read an article in March 27, 2006 issue of Business Week called “Programming at Warp Speed,” (seems software development is sexy again) about a company called 37 Signals (www.37signals.com). This company creates applications rapidly using the Ruby on Rails framework. They have an online book called “Getting Real” available on their Web site that documents the philosophies of this company and how they develop applications in a rapid manner. Some of the chapter titles include:


 


·         Interface First – Design the interface before programming


·         There’s Nothing Functional about a Functional Spec – The software developed usually doesn’t represent what you started with


·         Meetings are Toxic – The title says it all


 


Finally, I read a great article on the Gamasutra (www.gamasutra.com) Web site called “How to Prototype a Game in Under 7 Days: Tips and Tricks from 4 Grad Students Who Made Over 50 Games in 1 Semester.” Even game developers are having success with RAD/agile development techniques.


 


RAD/Agile development techniques work. They succeed because they deliver what customers want–quality software quickly. I highly recommend checking out these techniques for inclusion in your development process.


 



 


This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

5 Responses to RAD in the Time Of Agile Development

  1. Rai Sham says:

    i think the above explanation is not enough. There should be an addition of what are the uses of RAD and will it handle implicit risks or not. I am student of PU Pakistan and working on a project. I prefer the incremental model. What is the better approach in this perspective?

  2. Carlton says:

    I disagree with your assessment that RAD and agile software development are the same beast with different names. If you are referring to RAD as rapid application development, then there might be some similarities.

    However, most people use RAD to mean prototyping and agile software development (whatever flavor/author you are talking about) has nothing to do with prototyping. At the end of each cycle an agile project creates NOT a prototype, but a production ready application which provides real business value. If this is what you mean by RAD, than I disagree with this post.

  3. ewise says:

    I agree with much of what you said. The meetings are toxic thing though is debatable. The wrong kind of meetings are toxic, but face time with your customers is necessary and invaluable.

  4. Carl Camera says:

    I’ve read Getting Real and listened to Jason Fried speak at the 2006 South by Southwest Interactive conference. Much of what 37 Signals says rings true: time spent creating functional specs that no one reads or uses or updates is better spent designing the interface and application interactions that people care about and provide input to and want to improve.

    All meetings are not toxic. But many don’t move the project forward. They are called by management who get representatives from all the teams and “go around the room” and “provide status” so they can update their MS Project file. Argh!

    Rad/Agile is not appropriate for all projects. I wouldn’t want to use Rad when developing a 911 Emergency dispatch system. I don’t think you or 37signals would either.

  5. pvanooijen says:

    How nice !

    In the end it are all buzzwords, what they stand for is shifting. Rad used to stand for something good, these days it does have quite a smell. What agile stands for is open to debate as well. To me RAD stands mainly for visual designers and code generation. To me agile stands for “flexible”, doing the work in small steps, adapting all the time to the day-to-day reality of the project, communicating in all directions.

    Rad is a toolbox, agile is the way you work.

    Another buzzword used to be prototyping. Start with a prototype as a communication tool. What worked for me was keep building on the prototype, use it as a start for working code and not as a start for paperwork. The buzzword I miss is refactoring. You need a very good refactoring discipline (some tools would be handy as well…) to turn every iteration of your evolving project into maintainable code. Using RAD it’s easy to build things which look good on the outside; but it’s even easier to build things which look horrific on the inside. Refactor to keep your code clean.

    Am I missing more buzzwords ?

Leave a Reply