Friday, August 05, 2005

Technology Snake Oil, Part 2: RAD

Back in the mid-nineties, Rapid Application Development was the answer to all developer woes. RAD tools came out in droves and everyone touted the huge productivity gains made available by drag and drop user interface design and component based development. RAD environments made for great demo-ware -- you could stand in front of a group of Pointy Haired Boss types and build a working application right before their eyes while you were talking about it (I know because I did some of this -- and I still have trouble sleeping sometimes). Of course, the message was clear: buy This Tool, and you too can have developers that can point and click their way to huge productivity gains. And bought it they did.

Then a funny thing happened to the developers on the way to this astounding productivity. They learned the tools and dutifully dragged and dropped their way to building applications...and it was good. Until, that is, they figured out that building the application is the short, easy part -- now they have to maintain the monstrosity they've created. RAD development doesn't scale well, and when you build large and very large applications with it, maintaining those applications is a nightmare of searching for the scattered crumbs of code scattered hither and yon. Working for a while in this environment is what made the Design Patterns book really hit home -- the kind of code we were creating was entirely anti-pattern, and more about "how fast can it be created"? The maintenance nightmares led me, as CTO of a consulting and development company, to figure out new ways to use the RAD tools we had to use (because of our clients) that did follow good design principles. What we found is that the tools fight you when you try to do the right thing. RAD Development tools have a path of least resistance, which makes things very easy while you stay on the path (and use their wizards and other support structures). Stray from the path, and you find obstacles at every turn. But, it's worth fighting through them to get to a place where you can create maintainable code -- and you find that you are no longer doing Rapid Application Development, just Application Development.

RAD is now rightfully deprecated in most serious software development efforts. Even serious developers using RADish tools like Visual Studio are avoiding the RAD pitfalls. Some developers still fight with RAD tools, and think that maintenance is just always extremely difficult in big projects. I'm still shocked by the developers who have still never heard of Design Patterns and who still work on Sisyphean development chores.

Which is why I think the RAD aspect of Ruby on Rails misses the point of what makes Rails interesting. RAD doesn't work for large, complex projects, no matter what technology. The interesting part of Ruby on Rails is the effective use of Ruby to build a domain specific language on top of the underlying Ruby language that makes it easier to do web applications with persistence. It is more advanced than the RAD tools of old because you can drop to the underlying Ruby language and get underneath the framework when you must -- and that's a powerful idea. But, building complex applications in it still requires real thought. Maybe the breathless amazement of the Rails community reflects the absence of effective RAD tools in this space before. Don't get me wrong -- I think that Rails is cool, just not for the reasons touted by so many Rails-flavored Kool-aid carriers.

14 comments:

Anonymous said...

It is interesting to note that the original name for what is now called RAD was "Rapid Prototyping Tools." These were intended for mocking up UIs, not building them, but then the tools vendors realized that we were shipping the prototypes, and moved to where the money was.

Anonymous said...

Your comments on Rails are right on par with my thoughts. Rails is cool, but not because of a 10x productivity gain.

Katrina said...

Great info. I've now subscribed to this blog feed so I can access it within my rapid prototyping cnc site. This will make your blog one click away for me.

Katrina said...

Do you have an Rss feed to subscribe to? Im learning how to install an Rss reader and I'm learning. But it seems that I've been juggling the learning of design prototyping and development in general. I'll get it working though.

Katrina said...

I can't wait until I install my rss reader so I can subscribe to this blog. I'll have to finish building my rapid prototyping tooling site first so that I'll have a place to install the feed. Prototyping is my hobby.

Katrina said...

I can't wait until I install my rss reader so I can subscribe to this blog. I'll have to finish building my rapid prototyping tooling site first so that I'll have a place to install the feed. Prototyping is my hobby.

Katrina said...

I can't wait until I install my rss reader so I can subscribe to this blog. I'll have to finish building my rapid prototyping tooling site first so that I'll have a place to install the feed. Prototyping is my hobby.

Anonymous said...

Imagine Thousands Of Links Back To Your Web Site From Other People's Blogs!

Anonymous said...

Learn how to quickly create an RSS feeds with our RSS feeder, for high link popularity and ultimately better search engine rankings.

Anonymous said...

a lot of premium products and services being offered for free. What’s best is that there is a seemingly

Anonymous said...

This quick and easy system will automatically build you a customer email list by capturing your customer detailssoftware developmentsoftware development

Anonymous said...

Would The Thought Of Thousands Of Other Web Site's All Displaying Your Content,

Hajo said...

Not scaleable?
It is build on a web framework! You can scale linearly by putting more webservers behind the load balancer! Servers (Nowadays server instances; we run fully virtualized servers on blades) are a LOT cheaper than programmer hours! We're doing 6 to million inserts an hour. We run a 3.6 TB database (One of the largest MySQL installations in the world; They have a write up on their website).
As a side note on RAD tools: I have done Delphi work for both travel and telephone companies ($25 to $100 million dollars yearly revenues).
I do have 20 years of professional experience and both these tools (Delphi as well as Ruby on RAILS) are build on top of very solid, well thought out languages.

Hajo Smulders

Neal Ford said...

"Scalable" in this post is about development scaling (i.e., how big can you make the application in how much time, and how maintainable is it), not how many concurrent users you support. Very different things.