Jeff Palermo’s RAD kills. . . software - level 200 strikes a familiar chord with me. But I’d also like point out that although RAD isn’t something that I want to use when building an enterprise ready application, you have to watch out for the opposite of RAD, Analysis Paralysis. Where RAD lets you develop applications extremely fast, sacrificing performance, extensibility, scalability and maintainability, I’ve also seen shops where they spend way too much time in analysis of the domain. Back in the 90’s we called it Analysis Paralysis. What usually happens is that the lead developers/architects spend so much time arguing over how to model the system that they leave very little time to actually develop the system, or even worse, time to correct the things they missed in the original model.
So, if RAD is bad, and you have to watch out for Analysis Paralysis (AP), how do you architect a solution? Well, Agile Development Alliance has the following manifesto:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
I like to use a modified version of Test Driven Development to help combat AP. The idea is to use the xUnit framework to build a testing infrastructure while developing the libraries that make up the application. The test cases help flush out a usable application interface for each physical application layer, and also let you comfortably refactor your designs as you try to work out areas that don’t feel natural.
Don Box’s Pragmatics post is just as true for the RAD versus Enterprise Ready debate as it is for the REST versus SOAP:
If you want to reach both audiences before your competition does, you'll avoid indulging in religious debates and ship something.