Welcome to EMC Consulting Blogs Sign in | Join | Help

Simon Evans' Blog

My blog covers the technology areas I focus on here at EMC Consulting, namely Architecture using the .NET Framework, ASP.NET, WCF, WCF Data Services and Windows Azure Follow me on twitter @simonevans

10 Reasons why Agile is not Rapid Application Development (RAD)

A couple of weeks ago I was kindly given the opportunity to present at the Microsoft Architect Insight conference on the subject of Agile Architecture with my collegue Howard Van Roojen. We promised that we would post onto our blogs content from the presentation and any extra blogs covering topics we did not have time to cover. Up until now, this has not happened, as we have both been far too busy with projects going live. Well this week I plan to redress the balance by posting several articles on the topic, answering some of the questions we received, and documenting the presentation we gave.


This first post comes in response to feedback we received indirectly that Agile Architecture was basically RAD, because Agile processes use iterations and timeboxing which were first used in RAD. Whilst it is true that there are some similarities, there are also some key differentiators that make Agile projects very different in nature to RAD projects.


  1. Agile embraces the concept of contract first development required for either Object Orientated or Service Orientated architecture – RAD did not acknowledge the realities of designing to interfaces, partially because it preceded the widespread use of these techniques.
  2. Agile does not allow prototypes – RAD was based on designing prototypes and then reengineering them into production quality code (or not as was often the case).
  3. Agile projects logically break down the solution into features – the RAD approach did not do this; instead developers would focus on delivering all the features of the application by first doing it badly and then improving on the code base overtime..
  4. Agile teams are democratic. This means that the whole team has a say in the architecture of the solution, but the team is still lead by an architect. In contrast, RAD solutions were not based around the concept of a common architecture and thus individuals worked in silos.
  5. Agile development team members are self managing. In contrast, RAD teams are managed by a project manager. Note do not confuse the term management with leadership.
  6. Agile engineering practices (such as test driven development, and continuous integration) are stringent and thorough, ensuring that problems in the design or the code base are highlighted and fixed as quickly as possible, and that the team has the confidence to change the code base without breaking the product. None of these concepts were used in RAD projects.
  7. Agile teams focus on team communication and designing as a group. RAD teams tend to work as individuals, resulting in unmaintainable and poorly designed code.
  8. Agile teams only demonstrate completed work. RAD teams tend to demonstrate screen mockups, or prototypes, which lead the product owner to question why they now need to wait another six months for the completed product.
  9. Agile teams are based around disciplined individuals that remain continually focused on delivering real software. RAD teams lack discipline, simply because there was no structure to either the process, architecture or engineering practices.
  10. Agile teams are inclusive of testers and analysts and user experience specialists. RAD teams did not traditionally include non technical team members.


What is interesting about the comparison between RAD and Agile is that Agile projects are often labeled “cowboy developments”, because of the lack of heavy process. This is exactly the label that was given to RAD projects, because RAD had the key flaws described above. I feel those that label Agile projects this way are missing the point of Agile; the lightweight process coupled with the focus on production quality output works due to team interactions and group design sessions.

Published Tuesday, April 18, 2006 4:29 AM by simon.evans
Filed under: , , ,

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS



Julian On Software » Simon Evans’ Blog : 10 Reasons why Agile is not Rapid Application Development (RAD) said:

April 28, 2006 7:28 AM

IOpine said:

I found this to be very interesting. 
May 3, 2006 2:15 AM

Doug's Oracle Blog said:

That Peter Robson chap is taking over my blog again. I do wish he’d get his own sorted out   but, in the meantime, I’ll let him squat here for a while. Over to you, Peter …In an earlier guest submission, I made reference to following up a rather c
June 10, 2006 10:05 PM

Doug's Oracle Blog said:

That Peter Robson chap is taking over my blog again. I do wish he'd get his own sorted out  but, in the meantime, I'll let him squat here for a while. Over to you, Peter ...In an earlier guest submission, I made reference to following up a rather critica
June 10, 2006 11:08 PM

Doug's Oracle Blog said:

That Peter Robson chap is taking over my blog again. I do wish he'd get his own sorted out  but, in the meantime, I'll let him squat here for a while. Over to you, Peter ...In an earlier guest submission, I made reference to following up a rather critica
June 10, 2006 11:51 PM

Doug's Oracle Blog said:

That Peter Robson chap is taking over my blog again. I do wish he'd get his own sorted out  but, in the meantime, I'll let him squat here for a while. Over to you, Peter ...In an earlier guest submission, I made reference to following up a rather critica
June 11, 2006 3:53 PM

Application Development said:

Cross platform functional <a herf=” http://www.broadwayinfotech.com/web_development/web_applications.shtml”> application development </a> is a growing offshoot in software development services. Various companies seek professional application development helps to boost their process performance.

March 17, 2008 12:39 PM

Application development said:

"Every business is different in the terms of process, performance and infrastructure assemblage. So, why not a process-specific system and application set-up? <a herf=” http://broadwayinfotech.com/web_development/web_applications.shtml”>

Application development<a/> experts specialize in developing process-specific applications only.


April 5, 2008 6:50 AM

Vickoff Jean-Pierre said:

I am not english fluent for writing, but I read.

I compare RAD and Scrum : its exactly the same iteratve-incrementale-adaptative method (but RAD 1991, Scrum 1996). Scrum improve only one thing : the retrospective. XP improve the RAD Construction Phase (and seriously).

Read that : http://www.agilealliance.org/articles_by_category?id=82

May 25, 2009 9:11 PM

Application Development said:

The creative person who works as an application development should always think “out side the box”.  It has always been seen that diverse organizations have diverse application demands. While creating the software we should always keep the origination and the business in mind. For more info visit: http://www.adroitinfosystem.com/

November 26, 2010 12:20 PM

ebizuniverse.com said:

eBizUniverse, Inc is a Chicago based Web design, Internet Marketing (SEO) and software development company. See our extensive portfolio and get a FREE quote online

December 23, 2010 3:03 AM

Mark Iskandar said:

Your blog is viral

March 28, 2011 3:57 AM

Ahdil Ansareen said:

Who do you think you are? James Bond?

March 28, 2011 4:00 AM

Brendan Yun said:

i agree with ^ this is an excellent website. ^ he found it and then the whole class used it....by the way I think Im James bond

March 28, 2011 4:01 AM

Brandon Chau said:


March 28, 2011 4:03 AM

Mark Iskandar said:


March 28, 2011 4:03 AM

Jeffrey Jiang said:


March 28, 2011 4:04 AM

Brendan Yun said:

nobody knows but im actually a really big douch and im using ^ name to cover my stupidity

March 28, 2011 4:04 AM

Brandon Chau said:


March 28, 2011 4:05 AM

Brendan Yun said:

Wow whatahead ^

March 28, 2011 4:07 AM

Brendan Yun said:

Hi I'm a level 200 dark knight in maplestory. I'm the king of the Mapletopolis. People take their top off for me. I also think im james Bond

March 28, 2011 4:08 AM

Ahdil Ansareen said:

Hi I'm a level 200000000000000000000 dark knight in maplestory. I'm the king of the Mapletopolis. People take their top off for me. I also think im james Bond

March 28, 2011 4:08 AM

Ahdil Ansareen said:

me r j@mez b0nd!z0rs lol

March 28, 2011 4:08 AM

Ahdil Ansareen said:


March 28, 2011 4:09 AM

Johnny Yu said:

I'M OVER 9000!!!!!!!!

March 28, 2011 4:10 AM

Brandon Chau said:


March 28, 2011 4:11 AM

Aadil Ansareen said:

Wow. Some lame kid is impersonating me on this blog.

Far out. Who does he think he is, James Bond?

March 28, 2011 4:11 AM

Johnny Yu said:


March 28, 2011 4:11 AM

Aadil Ansareen said:

And he/she spelt my name wrong. Wow. Seriously. Who do you think you are? James *** Bond?

March 28, 2011 4:11 AM

Aadil Ansareen said:


March 28, 2011 4:12 AM

Aadil Ansareen said:

Yo Simon, delete Johnny Yu's comments. He doesn't seem to have anything constructive to add.

March 28, 2011 4:12 AM

Brian Chau said:

Agile methods are sometimes characterized as being at the opposite end of the spectrum from plan-driven or disciplined methods; agile teams may, however, employ highly disciplined formal methods.[10] A more accurate distinction is that methods exist on a continuum from adaptive to predictive.[11] Agile methods lie on the adaptive side of this continuum. Adaptive methods focus on adapting quickly to changing realities. When the needs of a project change, an adaptive team changes as well. An adaptive team will have difficulty describing exactly what will happen in the future. The further away a date is, the more vague an adaptive method will be about what will happen on that date. An adaptive team cannot report exactly what tasks are being done next week, but only which features are planned for next month. When asked about a release six months from now, an adaptive team may only be able to report the mission statement for the release, or a statement of expected value vs. cost.

Predictive methods, in contrast, focus on planning the future in detail. A predictive team can report exactly what features and tasks are planned for the entire length of the development process. Predictive teams have difficulty changing direction. The plan is typically optimized for the original destination and changing direction can require completed work to be started over. Predictive teams will often institute a change control board to ensure that only the most valuable changes are considered.

Formal methods, in contrast to adaptive and predictive methods, focus on computer science theory with a wide array of types of provers. A formal method attempts to prove the absence of errors with some level of determinism. Some formal methods are based on model checking and provide counter examples for code that cannot be proven. Generally, mathematical models (often supported through special languages see SPIN model checker) map to assertions about requirements. Formal methods are dependent on a tool driven approach, and may be combined with other development approaches. Some provers do not easily scale. Like agile methods, manifestos relevant to high integrity software have been proposed in Crosstalk.

Agile methods have much in common with the Rapid Application Development techniques from the 1980/90s as espoused by James Martin and others.

March 28, 2011 4:19 AM

simon.evans said:

I've traced ALL the recent comments to an IP in Sydney, NSW. A quick reference of your IP on Google Maps has shown the comments are coming 'Sydney Boys High School'. The names of the people commenting will be sent to the Sydney Boys contact email.

March 28, 2011 4:22 AM

Johnny Yu said:


March 28, 2011 4:23 AM

Anonymous said:

Simon Evans, why do you live?

March 30, 2011 12:11 PM

*** Smash said:

You guys are fucking retarded, just stfu.. wow its the internet, duhhh haha james bond -.- fucking tards

June 7, 2011 1:09 PM

Pot smoka said:

Shut up Smash, you don't know anything, ur a retard ffs

June 14, 2011 2:46 AM

Kiran Chikkla said:

Nice Article

January 5, 2012 9:30 AM

Mike said:

Thanks for the information. Clearly, you understand the methodology well.

June 1, 2012 12:10 PM

SiPlus said:

This is not "10 reasons why Agile is not RAD", this is "10 reasons why I don't like RAD".

January 20, 2013 5:24 PM

Interesting said:

Thanks for sharing. While this was informative, I agree with SiPlus's comment - this should be titled "10 reasons why I don't like RAD" or "Why I think Agile is better than RAD"! I was looking for an informative, balanced article - this one is the former but not the latter.

May 12, 2013 5:55 PM

DSOMS said:

Buti I thought agile was a group of methodologies, so comparing it with Rapid Application ......

I think that it would be better if you begin by explaining what agile is in few word and compare it with other heavy weight methodologies! thank you

November 16, 2013 3:25 PM

Obi said:

RAD hater.

December 13, 2013 3:57 AM

EJ said:

I worked on three RAD/JAD teams back when.  None of them were plagued by any of the weaknesses listed here.  They were organized, disciplined and did good work.  The agile team I'm on now is inefficient because it is over-burdened with process and involves many non-technical people who make and enforce bad decisions.  The importance of professional develops, and their experience, is devalued.  I'm not a fan.

December 19, 2013 8:36 PM

Bennie said:

Mr. Evans certainly addresses some of the problems associated with R.A.D., however, Agile can be just as bad.  It has been my experience (25+ years), that all methodologies have their pros and cons.  It is all in the execution and the individuals involved.  I have seen successful and failed projects executed in all methodologies.  I think one thing to keep in mind is this - R.A.D. started its popularity run in the early 90s when everyone started screaming client/server - we have to be client/server.  It was my experience that client/server projects executed under the R.A.D. methodology was a disaster - nothing worked - integration was dismal at best, etc.  

Just my observation.

July 31, 2014 4:28 AM

Leave a Comment


About simon.evans

Simon is a Managing Consultant for Conchango in the UK, part of EMC Consulting Services. He is an expert in .NET development, and more specifically in WCF and ASP.NET, having participated in several Microsoft early adoption programs. Simon believes deeply that a broad understanding of key technology concepts is an essential foundation to being a gifted designer and builder of solutions.
Powered by Community Server (Personal Edition), by Telligent Systems